Какая самая быстрая файловая система для сборок разработчиков?

Я собираю коробку Linux, которая будет действовать как сервер непрерывной интеграции; в основном мы будем создавать Java-вещи, но я думаю, что этот вопрос относится к любому скомпилированному языку.

Какие параметры файловой системы и конфигурации мне следует использовать? (Например, я знаю, что для этого мне не понадобится время!) Сервер сборки будет тратить много времени на чтение и запись небольших файлов и сканирование каталогов, чтобы увидеть, какие файлы были изменены.

ОБНОВЛЕНИЕ: целостность данных является низким приоритетом в этом случае; это просто сборочная машина ... последние артефакты будут заархивированы и архивированы в другом месте. Если файловая система на сборочной машине повреждена и теряет все данные, мы можем просто стереть ее и заново создать образ; билды продолжат работать, как и раньше.

Используйте ext4fs в качестве базовой файловой системы с несколькими вариантами ускорения, такими как

noatime,data=writeback,nobh,barrier=0,commit=300

Затем объедините монтирование виртуального диска tmpfs поверх него, чтобы файлы, записанные во время сборки, получили преимущества от виртуального диска. Либо измените процедуру сборки, чтобы переместить получившиеся двоичные файлы из tmpfs в конце сборки, либо объедините tmpfs обратно в ext4fs перед размонтированием.

Быстрая файловая система? tmpfs монтируется из свободной оперативной памяти, с noatimeустановленным.

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

К ответу Майкла Диллона я могу добавить, что вы можете создать файловую систему ext4 с несколькими опциями:

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 дает вам больше инодов для каждого размера, что полезно, потому что среда разработки создает много файлов.

Для источников предпочтительнее иметь поддержку сжатия на лету, например Reiser4 или Btrfs . Оба пока «не для производства», хотя я слышал о людях, которые активно и с удовольствием используют обе FS. :-)

Следующий выбор (я обычно делаю) - это Reiser3 , а не Ext3 . Ext3 может быть немного быстрее в настоящее время, но Reiser3 не имеет ограничений по времени форматирования i-узлов, поддерживает онлайновое изменение опции «data =». Он имеет «хвостовую» поддержку, позволяющую более плотно упаковывать крошечные файлы, но если вы беспокоитесь о скорости, «notail».

И XFS, и JFS были бы проблемой для «большого количества маленьких файлов», особенно если вам нужно их вызвать.

(Забыл упомянуть EXT4: Да, это даже быстрее, чем EXT3. Но все вышеупомянутые ограничения EXT3 тоже EXT4).

Операции, которые вы описываете, дают некоторые ключевые подсказки относительно того, что должна делать идеальная файловая система:

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

Btrfs и Ext4 - три из вышеперечисленных, а четвертый сомнительный. Ext4, вероятно, достаточно зрелый для этого, но btrfs еще не выпек. noatimeпомогает сделать операции с метаданными более эффективными, но когда вы создаете кучу новых файлов, вам все еще нужны операции мета-данных, которые должны быть очень быстрыми.

Именно тогда основное хранилище начинает становиться фактором. Операции метаданных XFS имеют тенденцию концентрироваться в нескольких блоках, которые могут напрягать операции. Файловые системы в стиле Ext лучше подходят для сближения метаданных с данными, которые они описывают. Однако, если ваше хранилище достаточно абстрактно (вы используете VPS или подключены к SAN), это не имеет большого значения .

Каждая файловая система имеет небольшие ускорения, которые можно сделать, чтобы получить еще несколько процентных пунктов. От того, насколько высокопроизводительным будет базовое хранилище, будет зависеть, сколько вы получите.

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

Для большого количества маленьких файлов я бы рекомендовал Reiser вместо ext3, xfs, jfs ..., хотя я слышал, что ext4 намного лучше (т.е. противоречит тому, что говорит poise), чем его предыдущие воплощения для этого шаблона доступа.

Reiser толкает множество файловых структур вверх по дереву inode, поэтому он отлично работает при работе с небольшими файлами.

Однако различия в поведении между ведущими файловыми системами относительно невелики по сравнению с преимуществами, которые вы получите, имея достаточно физической памяти для эффективного кэширования / буферизации.

и сканирование каталогов, чтобы увидеть, какие файлы были изменены.

Это дурацкий способ решения проблемы - хотя он и относительно простой. Если это так важно, подумайте о написании обработчика inotify для индексации модов.

OTOH, если вы используете флэш-SSD (что даст вам очень низкое время поиска), я бы рекомендовал использовать fs, которая распределяет запись более эффективно по причинам долговечности - например, JFFS2