Що найшвидша файлова система для розробників?

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

Які параметри файлової системи та конфігурації я повинен використовувати? (Наприклад, я знаю, що мені не потрібно буде atime для цього!) Сервер збирання витратить багато часу на читання та запис невеликих файлів та сканування каталогів, щоб побачити, які файли були змінені.

ОНОВЛЕННЯ: Цілісність даних є низьким пріоритетом у цьому випадку; це просто машина для складання ... остаточні артефакти будуть застебнені та архівовані в інших місцях. Якщо файлова система на машині збирання пошкоджується і втрачає всі дані, ми можемо просто стерти і перетворити зображення; збірки триватимуть, як і раніше.

Використовуйте ext4fs як базову файлову систему з кількома опціями прискорення, як-от

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

Потім об'єднайте tmfs ramdisk поверх цього, щоб файли, написані під час складання, отримували переваги ramdisk. Або змініть процедуру збірки, щоб перемістити отримані бінарні файли від 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) . І те й інше "ще не для виробництва", хоча я чув, як люди сильно та щасливо використовують обидва FSes. :-)

Наступний вибір (я зазвичай роблю) - це Reiser3 , а не Ext3 . На сьогоднішній день Ext3 може бути дещо швидшим, але Reiser3 не має обмежень часу і формату i-вузлів, підтримує он-лайн зміну опції "data =". Він має "хвостову" підтримку, що дозволяє чіткіше упакувати крихітні файли, але якщо вас турбує швидкість, "зауважте".

І XFS, і JFS будуть болем у випадку "безлічі невеликих файлів", особливо якщо вам потрібно їх переправити.

(Забув згадати EXT4: Так, це навіть швидше, тоді EXT3. Але всі вищезгадані обмеження EXT3 теж EXT4).

Описані вами операції дають деякі основні підказки щодо того, що ідеальна файлова система повинна вміти робити:

• Масово випадкові r / w доступу в процесі збирання.
• Багато, багато файлів оновлюються в короткі терміни, тому швидкі операції з метаданими є критичними.
• Ефективна робота з багатьма маленькими файлами на можливо дуже файлових файлових системах.
• Досить зрілий, щоб не ризикувати втратою даних у нечастому і незрозумілому краєвиді.

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

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

Кожна файлова система має невеликі прискорення, які можна зробити, щоб отримати ще кілька відсоткових пунктів. Наскільки ефективними є базові сховища, значно впливатиме на те, який прибуток ви побачите.

Якщо говорити про зберігання, якщо у вас є достатня кількість операцій вводу-виводу у вашому сховищі, неефективність файлової системи починає не так сильно мати значення. Якщо ви використовуєте SSD для свого розділу збору, вибір файлової системи є менш важливим, ніж те, з чим вам зручніше працювати.

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

Рейзер підштовхує багато структури файлів вгору до дерева inode - тому він працює дуже добре при роботі з невеликими файлами.

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

і сканування каталогів, щоб побачити, які файли були змінені.

Це хитрий спосіб вирішити проблему - навіть якщо вона порівняно проста. Якщо це важливо, подумайте про те, щоб написати інноваційний обробник для індексації модників.

OTOH, якщо ви використовуєте флеш-накопичувач (це дасть вам дуже низький час пошуку), я б рекомендував використовувати fs, який більш ефективно розповсюджує записи з міркувань довголіття - наприклад, JFFS2