Я собираю Linux, который будет действовать как сервер сборки непрерывной интеграции; в основном мы будем создавать материалы на Java, но я думаю, что этот вопрос применим к любому компилируемому языку.
Какие параметры файловой системы и конфигурации мне следует использовать? (Например, я знаю, что мне не понадобится время для этого!) Сервер сборки будет тратить много времени на чтение и запись небольших файлов и сканирование каталогов, чтобы увидеть, какие файлы были изменены.
ОБНОВЛЕНИЕ: целостность данных в этом случае имеет низкий приоритет; это просто машина для сборки ... конечные артефакты будут заархивированы и заархивированы в другом месте. Если файловая система на машине сборки будет повреждена и потеряет все данные, мы можем просто стереть и заново создать образ; сборки будут продолжать работать как раньше.
Самая быстрая файловая система? tmpfs, смонтированный из доступной оперативной памяти, с noatime устанавливать.
Это возможно только в том случае, если у вас есть процедура для проверки всего, что необходимо для построения вашего исходного дерева (поскольку содержимое файловой системы tmpfs исчезнет при перезагрузке), и если источник и объекты помещаются в разумный угол вашей доступной оперативной памяти ( с остатком, достаточным для запуска вашего компилятора и компоновщика без подкачки). Тем не менее, вы не можете превзойти работу с ОЗУ по скорости ..
Используйте ext4fs в качестве базовой файловой системы с несколькими параметрами ускорения, такими как
noatime,data=writeback,nobh,barrier=0,commit=300
Затем объедините монтируемый ramdisk tmpfs поверх этого, чтобы файлы, записанные во время сборки, получили преимущества ramdisk. Либо измените процедуру сборки, чтобы переместить полученные двоичные файлы из tmpfs в конце сборки, либо объедините tmpfs обратно в ext4fs перед размонтированием.
К ответу Майкла Диллона я могу добавить, что вы можете создать файловую систему 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 дает вам больше inodes на размер, что полезно, потому что среды сборки создают много файлов.
Для источников предпочтительно иметь поддержку сжатия на лету, т.е. Reiser4 или Btrfs. Оба они пока «не для продакшена», хотя я слышал о людях, активно и с удовольствием использующих обе FS. :-)
Следующий выбор (обычно так и делаю): Reiser3не Ext3. Ext3 может быть немного в настоящее время работает быстрее, но Reiser3 не имеет ограничений по времени форматирования i-узлов, поддерживает оперативное изменение параметра «data =». У него есть «хвостовая» поддержка, позволяющая более плотно упаковывать крошечные файлы, но если вас беспокоит скорость, не делайте этого.
И XFS, и JFS были бы проблемой для случая "большого количества маленьких файлов", особенно если вам нужно их удалить.
(Забыл упомянуть EXT4: да, он даже быстрее, чем EXT3. Но все вышеупомянутые ограничения EXT3 относятся и к EXT4).
Описанные вами операции дают некоторые ключевые подсказки относительно того, что должна уметь идеальная файловая система:
Btrfs и Ext4 - это три из вышеперечисленных, а четвертый под вопросом. Ext4, вероятно, достаточно зрелый для этого, но btrfs еще не готов. noatime помогает сделать операции с метаданными более эффективными, но когда вы создаете кучу новых файлов, вам все равно нужно, чтобы операции с метаданными были невероятно быстрыми.
Вот когда основное хранилище начинает играть важную роль. Операции с метаданными XFS, как правило, сосредоточены в нескольких блоках, что может затруднить выполнение операций. Файловые системы в стиле Ext лучше подходят для приближения метаданных к данным, которые они описывают. Однако, если ваше хранилище достаточно абстрактно (вы работаете на VPS или подключены к SAN) это не имеет большого значения.
У каждой файловой системы есть небольшие приросты, которые можно сделать, чтобы получить еще несколько процентных пунктов. От того, насколько производительна базовая система хранения, сильно повлияет ваш выигрыш.
Говоря языком хранилища, если у вас достаточно накладных расходов на операции ввода-вывода в хранилище, неэффективность файловой системы начинает не иметь большого значения. Если вы используете SSD для раздела сборки, выбор файловой системы менее важен, чем то, с чем вам удобнее работать.
Для большого количества небольших файлов я бы рекомендовал Reiser вместо ext3, xfs, jfs ..., хотя я слышал, что ext4 намного лучше (то есть противоположно тому, что говорит poise), чем его предыдущие воплощения для этого шаблона доступа.
Reiser подталкивает большую часть файловой структуры вверх по дереву индексных дескрипторов, поэтому он отлично работает при работе с небольшими файлами.
Однако различия в поведении между ведущими файловыми системами относительно невелики по сравнению с преимуществами, которые вы получите, имея достаточно физической памяти для эффективного кеширования / буферизации.
и сканирование каталогов, чтобы увидеть, какие файлы были изменены.
Это дрянной способ решить проблему, хотя и относительно простой. Если это так важно, подумайте о написании inotify обработчик для индексации модов.
OTOH, если вы используете флэш-накопитель SSD (который даст вам очень низкое время поиска), я бы рекомендовал использовать fs, который более эффективно распределяет запись по соображениям долговечности - например, JFFS2