Выбор размера блока файловой системы

Размер блока - это своего рода артефакт из былых времен файловых систем, где память и хранилище были ценными товарами, поэтому даже указатели на данные должны были быть оптимизированы по размеру. MS-DOS использовала 12-битные указатели для ранних версий FAT, что позволяло управлять до 2 ^ 12 = 4096 блоков (или файлов). Поскольку максимальный размер файловой системы по своей природе ограничен (max_block_size) Икс (max_block_number)"правильный" размер блока был скорее проблемой, когда вам приходилось думать об общем размере вашей файловой системы и о том, сколько места вы потратите впустую, выбрав больший размер блока.

Поскольку современные файловые системы будут использовать 48-битные (ext4), 64-битные (NTFS, BTRFS) или даже 128-битные (ZFS) указатели, что позволяет использовать огромные (с точки зрения количества блоков) файловые системы, выбор размера блока стал Это менее важная проблема, если у вас нет конкретного приложения и вы не хотите его оптимизировать. Примеры могут быть

• блочные устройства с большими блоками, где вы не хотите, чтобы разные файлы «совместно использовали» один физический блок в целях оптимизации производительности - в этом случае выбираются большие блоки файловой системы, соответствующие размеру блока физического устройства
• программное обеспечение для ведения журнала, которое будет записывать большое количество файлов фиксированного размера, которые вы хотите оптимизировать для использования хранилища, выбирая размер блока, соответствующий вашему типичному размеру файла

Поскольку вы специально просили ext2 / 3 - к настоящему времени это довольно старые файловые системы, использующие 32-разрядные указатели, поэтому с большими устройствами вам, возможно, придется запускать те же "максимальный размер файловой системы по сравнению с потраченным впустую пространством" соображения, о которых я писал ранее.

Производительность файловой системы мощь страдают от большого количества блоков, используемых для одного файла, поэтому может иметь смысл больший размер блока. В частности, ext2 имеет довольно ограниченное количество ссылок на блоки, которые могут храниться непосредственно с inode и файлом, потребляющим большое количество блоков. необходимо будет ссылаться на четыре уровня связанных списков:

Таким образом, очевидно, что файл с меньшим количеством блоков потребует меньше опорных слоев и, таким образом, теоретически обеспечит более быстрый доступ. При этом интеллектуальное кэширование, вероятно, на практике скроет большинство аспектов производительности этой проблемы.

Еще один аргумент, который часто используется в пользу блоков большего размера: фрагментация. Если у вас есть файлы, которые постоянно растут (например, журналы или базы данных), малые размеры блоков файловой системы могут привести к большей фрагментации данных на диске, что снизит вероятность последовательного чтения больших блоков данных. Хотя это по своей сути верно, вы всегда должны помнить, что в подсистеме ввода-вывода, обслуживающей несколько процессов (ступеней / пользователей), последовательный доступ к данным очень маловероятно для универсальных приложений. Тем более, если вы виртуализировали свое хранилище. Таким образом, самой фрагментации недостаточно в качестве оправдания для выбора большего размера блока во всех случаях, кроме некоторых угловых.

Как общее практическое правило, которое справедливо для любой разумной реализации FS, вы должны оставить размер блока по умолчанию, если у вас нет конкретной причины предполагать (или, что еще лучше, показывать тестовые данные) какой-либо выгоды от выбора не -размер блока по умолчанию.

Для более современных систем, включающих твердотельные накопители, самые последние твердотельные накопители работают намного лучше с размером блока 4K, чем с размером блока 512Б, в основном потому, что используемые SSD-страницы флэш-памяти NAND имеют размер не менее 4K.