Выбор размера блока файловой системы
Учитывая специфические файловые системы unix/linux/bsdunix:
Как я могу выбрать / узнать, какой размер блока использовать при создании файловой системы? Существует ли какое-либо конкретное значение размера блока для конкретной файловой системы, которое считается наиболее эффективным для этой конкретной файловой системы?
Допустим, я выбираю большой размер блока для своей файловой системы, очевидно, он будет быстро записывать / читать данные для больших файлов. Для небольших файлов это приведет к фрагментации пространства (поправьте меня, если я ошибаюсь). Итак, какие приложения обычно используют большой размер блока fs, а какие используют небольшой размер блока?
Также выбор размера блока влияет на то, какую файловую систему использовать? Так это как для определенного размера блока, производительность FS лучше с одной FS(скажем, ext3) и не так хороша для другой FS(скажем, ext2 или vxfs или любой fs для той же ОС)?
2 ответа
Размер блока является своего рода артефактом с давних времен файловых систем, где память и хранилище были ценными товарами, поэтому даже указатели на данные должны были быть оптимизированы по размеру. 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, вы должны оставить размер блока по умолчанию, если у вас нет особых причин предполагать (или, что еще лучше, показывать тестовые данные) какую-либо выгоду от выбора не размер блока по умолчанию.
Для более новых систем, включающих SSD, большинство недавно построенных SSD работают намного лучше с размерами блоков 4K, чем с размерами блоков 512B, в основном потому, что флэш-страницы NAND, используемые SSD, имеют размер не менее 4K.