Уровень файловых систем

На уровне файловой системы последовательный поток байтов, следующий от приложения, организуется в блоки. Именно здесь определяются нижняя и верхняя границы Request Size.

Минимально возможный Request Size задается размером блока файловой системы. Правда, в некоторых системах метаданные могут записываться порциями меньшими, чем размер блока, но их общий объем не велик и обычно не влияет на характер I/O. Размер блока зависит от типа и параметров файловой системы. Он обычно задается одним из трех способов:

• Фиксированный размер, по умолчанию или заданный явно при создании файловой системы. Например, default block size в Solaris UFS = 8K.
• Фиксированный размер, определяемый по величине создаваемой файловой системы (file system size). Так в NTFS при размерах тома 513MB - 1,024GB block size = 1KB, при 1,025GB – 2GB block size = 2KB, а при 2 – 4GB block size = 4KB.

Многие файловые системы поддерживают оба способа, например, при создании ext2 можно либо явно задать размер блока 1KB, 2KB или 4KB (mke2fs –b), либо позволить утилите mk2fs самой определить требуемый block size, исходя из величины файловой системы (по умолчанию).

• Размер, динамически изменяемый в процессе записи данных на файловую систему. Например, ZFS в зависимости от текущих параметров ввода-вывода позволяет записывать данные блоками различных размеров (до 128KB).

При настройке block size не стоит забывать, что все файловые системы буферизуют данные в системной области оперативной памяти сервера. Поэтому больший размер блока приведет к уменьшению объема RAM, доступного для приложений.

Несколько последовательных блоков в буфере могут быть объединены в единый запрос. Каждая файловая система имеет параметр, определяющий, какое максимальное количество блоков может быть объединено. Зная этот параметр, мы можем легко вычислить максимальный размер запроса к дисковому массиву. Например, если файловая система позволяет объединять не более 128 блоков размером 8KB, то максимальный размер Request Size равен 1MB (128 * 8KB).

Во вновь созданной файловой системе блоки данных файлов имеют последовательно идущие LBA. Фрагментация файловой системы приводит к тому, что даже если с точки зрения приложений операции чтения и записи производятся последовательно, то на уровне файловой системы они все равно не могут эффективно объединяться в большие запросы. Таким образом, sequential операции превращаются в random, что увеличивает накладные расходы на их обработку и очень заметно сказывается на общей производительности. Поэтому, если файловая система предполагает наличие значительного количества последовательных запросов (например, резервное копирование данных), необходимо регулярно проводить ее дефрагментацию.

Базы данных обычно имеют свою собственную буферизацию. Для того чтобы избежать неэффективного использования ресурсов за счет двойной буферизации, в некоторых случаях резонно не использовать дополнительную прослойку файловой системы, а передавать данные напрямую на сырые устройства (raw devices).

Raw devices не имеют ограничений на размер блока и поэтому позволяют варьировать размеры Request Size в более широком диапазоне. В силу своей организации они также не подвержены фрагментации на уровне блоков.
В тоже время, использование сырых устройств усложняет управление, а также резервное копирование и восстановление данных. В современных системах с большим объемом оперативной памяти, файловые системы часто показывают более высокое быстродействие, чем сырые устройства.