Обычно для увеличения скорости работы используются специальные механизмы кэширования операций чтения и записи.
Применяя в ОС оба типа кэширования позволяет разработчикам ЗНАЧИТЕЛЬНО ускорить операции ввода-вывода. Например, кэширование операций записи позволяет «собрать» множество операций ввода-вывода в единый пакет изменений и за одно-два обращения к диску (в моменты меньшей загрузки) их записать.
Однако хранение в памяти незаписанной на диск информации в памяти опасно – в случае сбоя потеряется информация и нарушится логическая структура файловой системы. Проверка файловой системы после сбоя может занять много времени. Например, проверка 8 гигабайт файловой системы ext2fs занимает 15-20 минут (тестовое оборудование 1999г.в.).
Поэтому используют специальные журналы операций – в них записывается информация сразу. Если происходит сбой, то происходит проверка на основании этого журнала, при этом обеспечивается высокая скорость проверки и восстановления – в среднем не более 30 секунд(на примере раздела в 12Гб, оборудование 2003-2006г.в.).
Файловая система ReiserFS оказалась для Linux исторически первой - она поддерживается ядром, начиная с первых версий ветви 2.4.x и была единственной, разработанной "с нуля" специально для этой ОС Хансом Райзером. Как и в большинстве таких систем здесь осуществляется журналирование только операций над метаданными файлов. Кроме этого, ReiserFS обладает уникальной возможностью оптимизации дискового пространства, занимаемого мелкими файлами - они целиком хранятся в своих inode, без выделения блоков в области данных и вместе с экономией места это способствует и росту производительности, так как данные и метаданные хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода. Другая особенность ReiserFS - хвосты файлов меньше чем один блок могут быть подвергнуты упаковке (режим тайлинга). Это обеспечивает около 5% экономии дискового пространства.
В отличие от ReiserFS, ext3fs - не более чем журналируемая надстройка над классической ext2fs, разработанная в компании Red Hat и поддерживаемая ядром Linux, начиная с 2.4.16. Как следствие такого происхождения, она сохраняет со своей прародительницей полную совместимость, в том числе и на уровне утилит обслуживания. Другое преимущество - чуть ли не максимальная надежность: ext3fs является системой, в которой возможно журналирование операций не только с метаданными, но и с данными.
В ext3fs предусмотрено три режима работы: полное журналирование (full data journaling), журналирование с обратной записью (writeback), а также задействуемое по умолчанию последовательное (ordered). В первом случае все новые данные сначала пишутся в файл журнала и только после этого фиксируются на диске. В случае аварийного отказа можно повторно перечитать журнал, приведя данные и метаданные в непротиворечивое состояние. Этот механизм практически гарантирует от потерь данных, однако является наиболее медленным. В режиме с обратной записью в файл журнала записываются только изменения метаданных и никакой гарантии сохранности данных он не предоставляет, однако обеспечивает наибольшее (в рамках ext3fs) быстродействие. В последовательном режиме также физически журналируются только метаданные файлов, однако, связанные с ними блоки данных логически группируются в единый модуль, называемый транзакцией. И эти блоки сохраняются перед записью на диск новых метаданных, что, хотя и не гарантирует полной сохранности, но весьма способствует ей.
Файловая система XFS, в отличие от «молодых» ReiserFS и ext3fs, развивается на протяжении более десяти лет - впервые она появилась для версии Irix 5.3 в 1994 г. XFS - 64-разрядная файловая система. Особенностями XFS являются:
механизм allocation group - деление единого дискового раздела на несколько равных областей, имеющих собственные списки inodes и свободных блоков, для распараллеливания дисковых операций;
логическое журналирование только изменений метаданных, но с частым сбросом их на диск для минимизации возможных потерь при сбоях;
механизм delayed allocation - ассигнование дискового пространства при записи файлов не во время журналирования, а при фактическом сбросе их на диск, что, вместе с повышением производительности, предотвращает фрагментацию дискового раздела;
списки контроля доступа (ACL, Access Control List) и расширенные атрибуты файлов (extended attributes).
XFS очень сбалансированная файловая система - она почти столь же надежна, как ext3fs, и не уступает ReiserFS в быстродействии на большинстве файловых операций. А при манипуляциях с очень большими файлами XFS вне конкуренции. Не отмечалось для нее и проблем с совместимостью.
NTFS является восстанавливаемой (recoverable) файловой системой. Она гарантирует согласованность данных тома, используя стандартную процедуру регистрации транзакций. Каждая операция ввода-вывода, которая изменяет файл на томе NTFS, рассматривается файловой системой как транзакция.
При модификации файла специальная компонента файловой системы - сервис регистрации файлов (Log File Service) - фиксирует всю информацию, необходимую для повторения или отката транзакции в специальном файле с именем $LogFile. Если транзакция не завершается нормально, то NTFS пытается закончить транзакцию (повторить) или производит ее откат. Этот метод обеспечивает минимальное время восстановления, однако восстанавливаются только системные данные (метаданные), пользовательские же данные могут быть утеряны.
Распределенные системы часто обеспечивают репликацию (тиражирование) файлов в качестве одной из услуг, предоставляемых клиентам. Репликация - это асинхронный перенос изменений данных исходной файловой системы в файловые системы, принадлежащие различным узлам распределенной файловой системы. Имеется несколько причин для предоставления этого сервиса, главными из которых являются:
Увеличение надежности за счет наличия независимых копий каждого файла на разных файл-серверах.
Распределение нагрузки между несколькими серверами.
При обработке больших массивов данных бывает полезно все реплицировать на отдельный сервер и там анализировать
Как обычно, ключевым вопросом, связанным с репликацией является прозрачность. До какой степени пользователи должны быть в курсе того, что некоторые файлы реплицируются? Должны ли они играть какую-либо роль в процессе репликации или репликация должна выполняться полностью автоматически? В одних системах пользователи полностью вовлечены в этот процесс, в других система все делает без их ведома. В последнем случае говорят, что система репликационно прозрачна.
Есть три варианта репликации показанные на рисунке:
а) Точная репликация файла. Когда процесс создает файл, он делает это на одном определенном сервере, затем при необходимости создаются дополнительные копии на других серверах. Если сервер каталогов разрешает сделать несколько копий файла, то сетевые адреса всех копий могут быть ассоциированы с именем файла, как показано на рисунке снизу, и когда имя найдено, это означает, что найдены все копии. Эта схема хотя и работает, но имеет много недостатков, и по этим причинам ее не стоит использовать в распределенных системах.
б) Ленивая репликация файла. Здесь создается только одна копия каждого файла на некотором сервере. Позже сервер сам автоматически выполнит репликации на другие серверы без участия программиста. Эта система должна быть достаточно быстрой для того, чтобы обновлять все эти копии, если потребуется.
в) Репликация файла, использующая группу. В этом методе все системные вызовы ЗАПИСАТЬ передаются одновременно на все серверы, таким образом копии создаются одновременно с созданием оригинала.
Имеется два принципиальных различия в использовании групповых связей и ленивой репликации. Во-первых, при ленивой репликации адресуется один сервер, а не группа. Во-вторых, ленивая репликация происходит в фоновом режиме, когда сервер имеет промежуток свободного времени, а при групповой репликации все копии создаются в одно и то же время.
Существует проблема отслеживания изменений и репликация их на другие сервера. Существует несколько хорошо известных алгоритма решения этой проблемы:
Первый алгоритм, называемый "репликация первой копии", требует, чтобы один сервер был выделен как первичный. Остальные серверы являются вторичными. Когда реплицированный файл модифицируется, изменение посылается на первичный сервер, который выполняет изменения локально, а затем посылает изменения на вторичные серверы.
Чтобы предотвратить ситуацию, когда из-за отказа первичный сервер не успевает оповестить об изменениях все вторичные серверы, изменения должны быть сохранены в постоянном запоминающем устройстве еще до изменения первичной копии. В этом случае после перезагрузки сервера есть возможность сделать проверку, не проводились ли какие-нибудь обновления в момент краха. Недостаток этого алгоритма типичен для централизованных систем - пониженная надежность.
Чтобы избежать его, используется метод, предложенный Гиффордом и известный как "голосование". Пусть имеется n копий, тогда изменения должны быть внесены в любые W копий. При этом серверы, на которых хранятся копии, должны отслеживать порядковые номера их версий. В случае, когда какой-либо сервер выполняет операцию чтения, он обращается с запросом к любым R серверам. Если R+W > n, то, хотя бы один сервер содержит последнюю версию, которую можно определить по максимальному номеру. Этот метод требует наличия у каждого файла специального числа – «версия».
Интересной модификацией этого алгоритма является алгоритм "голосования с приведениями". В большинстве приложений операции чтения встречаются гораздо чаще, чем операции записи, поэтому R обычно делают небольшим, а W - близким к N. При этом выход из строя нескольких серверов приводит к отсутствию кворума для записи. Голосование с приведениями решает эту проблему путем создания фиктивного сервера без дисков для каждого отказавшего или отключенного сервера. Фиктивный сервер не участвует в кворуме чтения (прежде всего, у него нет файлов), но он может присоединиться к кворуму записи, причем он просто записывает в никуда передаваемый ему файл. Запись только тогда успешна, когда хотя бы один сервер настоящий.
Когда отказавший сервер перезапускается, то он должен получить кворум чтения для обнаружения последней версии, которую он копирует к себе перед тем, как начать обычные операции. В остальном этот алгоритм подобен основному.
