FreeBSD vs Linux: швидкодія файлових систем

1. Цілі і завдання
2. Учасники тестування
3. Про тестової платформі
4. об'єкти тестування
5. результати
6. UFS
7. Ext2fs
8. Ext3fs
9. ReiserFS
10. XFS
11. JFS
12. Висновки

Олексій Федорчук
2004 р

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

Цілі і завдання

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

Однак теоретично чисто асинхронний режим існує і в FreeBSD, хоча використання його вкрай не рекомендується у всіх офіційних документах проекту, як сприяє падінню надійності. Що, безумовно, вірно для серверів, але не здається такою вже критичним для десктопів, оснащених бесперебойніка (а бесперебойник, на мою скромну думку, - неодмінний атрибут будь-якої Unix-машини, особливо в умовах пострадянської дійсності). Так що виникло природне бажання - подивитися, а як веде себе UFS2 в асинхронному режимі.

Відразу зауважу, що перші ж результати вимірювань виявилися дещо несподіваними і, по крайней мере для мене - не цілком зрозумілими. І тому для прояснення ситуації я вирішив порівняти їх з проведеними в аналогічних умовах вимірами для ext2fs в Linux. Ну а далі - більше, стало цікавим зіставлення з іншими файловими системами Linux. І, нарешті, виникло питання, а як ці операційки працюють з файловими системами один одного. Оскільки підтримка в Linux UFS2 нині не реалізована (та й включити підтримку UFS просто - завдання не тривіальна), довелося обмежитися вимірами тільки для ext2fs під FreeBSD. Таким чином і визначилися

Учасники тестування

Отже, першим учасником, природно, стала UFS2, утворена з параметрами за замовчуванням sysinstall (розмір блоку - 16384 байт, розмір фрагмента - 2048), з передбаченим цією програмою включенням режиму SoftUpdates. І вмонтовується в умолчальне ж, тобто частково асинхронному (опція -o noasync, яка приймається за замовчуванням при виконанні команди mount) режимі.

Далі, виходячи із загальних міркувань, можна було припускати, що на швидкодію файлових операцій може впливати також опція -o noatime, що забороняє оновлення часу останнього доступу для файлів. Потім, зрозуміло, був випробуваний чисто асинхронний режим (опція -o async). І, нарешті, поєднання обох опцій, від якого теоретично слід чекати максимальної швидкодії.

Як об'єкти порівняння виступили нативні файлові системи Linux. В першу голову це, звичайно, була класична ext2fs, монтувати в двох режимах - умолчальне і в режимі -o noatime.

Потім - її журнальованою варіант, ext3fs. Для неї штатно передбачено три режими використання - повного журналювання (опція -o data = journal), при якому фіксуються операції не тільки з метаданими файлів, але і їх даними, стандартного часткового журналирования (опція -o data = ordered, при якій дані і метадані групуються в єдиний блок транзакції) і режиму writeback, в якому ніякого журналирования даних не здійснюється. Від використання опції -o noatime я в даному випадку відмовився (чесно кажучи, просто з ліні - хоча, як стало зрозумілим із результатів, нічого принципово нового ця опція не дала б).

Далі - ReiserFS, сама претензійна (і, мабуть, найбільш популярна серед користувачів Linux) журнальована файлова система. Тут, крім умолчальне, я знову випробував режим з відмовою від поновлення atime - і, як показала практика, не дарма).

Аналогічно я поступив і з XFS - вимірювання на ній проводилися в умолчальне режимі і в режимі з опцією -o noatime. І, нарешті, щодо JFS я обмежився режимом за замовчуванням - так як цією системою ніколи практично не користувався, мало чого про неї знаю і привернув її до справи виключно для порівняння.

Всі файлові системи створювалися за допомогою відповідних утиліт (mke2fs - для ext2fs і ext3fs, mkreiserfs і mk.xfs - для однойменних файлових систем, jfs_mkfs - для JFS) з параметрами за замовчуванням. Винятком стала XFS, для якої розмір allocation group і обсяг журналу були підібрані в відповідність до рекомендацій Деніела Роббінса (обсяг журналу - 32 Мбайт, мінімум одна allocation group на 4 Гбайт дискового простору, відведеного під цю файлову систему).

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

Про тестової платформі

Виміри проводилися на підручному залозі, якесь містило:

• процесор Pentium-4 / 2,53 Ггц, FSB 533, без HT;
• материнська плата Albatron PX845PE на однойменному чіпсеті, у варіанті з додатковим контролером ATA RAID / SerialATA Promise FastTrack 376 (втім, не задіяним);
• 1 Гбайт оперативної пам'яті (2 × 512 PC-2700, що продавалася під брендом «нібито Samsung»);
• жорсткий диск Seagate Barracuda IV 40 Гбайт, інтерфейс ParallelATA, 7200 об. / хв., підключений як single на 1-й канал стандартного ATA-контролера з південного моста ICH4.

Інші компоненти, типу CD-ROM (single на другому IDE-каналі), значення в даному випадку не мають.

На диску було 4 первинний розділу. Перший, об'ємом 30 Мбайт з файлової системою ext2fs, виконував функції завантажувального і ніс на собі тільки GRUB (і ядро ​​Linux). Другий розділ був визначений як BSD-слайс, і в ньому, на файлової системі UFS2, розміщувалася FreeBSD 5.2.1. Третій розділ був оголошений DOS Extended і ніс на собі Archlinux 0.6 (ядро 2.6.6). Деталі їх розбиття, а також файлові системи, в даному контексті не істотні.

У про уникнення непорозумінь зауважу, що в обох ОС диск функціонував в штатному режимі UDMA100, що визначалося утилітами atacontrol у FreeBSD і hdparm в Linux.

І ще: FreeBSD була піддана процедурі make world з прапорами оптимізації -O1 і -march = pentium4. Ядро, пересобран на базі дуже полегшеного GENERIC (з виключенням підтримки всього відсутнього, типу SCSI і мережевих карт), компілювати з прапором -O2 під той же Pentium-4. Для Archlinux використовувалося штатний прекомпілірованние (зі сховищ проекту - current) ядро, зібране, як і вся система в цілому, з прапорами -O2 -march = i686.

Втім, все сказане в попередньому абзаці навряд чи здатне було кардинально вплинути на продуктивність при файлових операціях. І тому для нас важливий тільки четвертий первинний розділ, обсягом 5,5 Гбайт, який і піддавався всіляким знущань. Для чого на ньому, після присвоєння відповідного ідентифікатора (4.2BSD або Linux native, відповідно), на ньому створювалися перераховані в попередньому розділі файлові системи, які монтувалися з зазначеними опціями. А на них вже містилися ті дані, які представляли собою

об'єкти тестування

Вимірювання я затівав для особистих цілей, і тому мене найбільше цікавили операції з тими даними, з яким я маю справу регулярно. А це а) масиви змішаних даних (тексти і ілюструє їх графіка), б) масиви з величезної кількості дуже маленьких файлів (типу дерева портів FreeBSD і аналогічних систем управління пакетами з Source Based дистрибутивів Linux) і в) великі файли, від обсягу CD і вище. У відповідність з цим я і підібрав тестові об'єкти.

По-перше, це був каталог моїх робочих матеріалів - файлів в форматах plain text і html з ілюстраціями в форматах gif, tiff, jpeg, png, обсяг яких варіював від декількох кілобайт до перших десятків мегабайт. Для пожвавлення картини я розбавив його звуковими файлами mpeg (від 1,5 до 6 Мбайт кожен). В результаті перший тестовий масив сумарно склав 830 Мбайт.

Другим об'єктом було підручний дерево портів FreeBSD від 6 травня 2004 року, обсягом 24,2 Мбайт, і результат його «розтарування», що давало каталог в 124 Мбайт. Специфіка його - в тому, що він утворений величезним (понад 100 тисяч) кількість файлів, переважаючий розмір яких - кілька сот байт.

Нарешті, третім об'єктом став avi-файл розміром в CD - 693 Мбайт.

Нічого кращого, ніж вимірювати час копіювання цих масивів, я не придумав. Тобто каталог даних копіювався командою виду

$ Cp data newdata

з подальшим знищенням цільового каталогу

$ Rm -Rf newdata

і замірів часу кожної операції за допомогою виведення команди date до і після неї. Аналогічно я поступав і з великим файлом. А тарбалл портів попередньо розвертався командою

$ Tar xzvf ports.tar.gz

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

date >> file_of_result && command1 && date >> file_of_result && ... date >> file_of_result &&

Всі три тести для кожної файлової системи в кожному режимі виконувалися тричі. По завершенні циклу файлова система демонтувати і перед повторенням монтувалася заново. Як результуючих приймалося середнє арифметичне з трьох значень.

результати

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

UFS

Почнемо з тієї, що послужила першопричиною цієї замітки - з UFS2. Нагадаю, що вона монтувалася послідовно в чотирьох режимах - умолчальне, з включенням опції -o noatime, в чисто асинхронному режимі (опція -o async) і, нарешті, з включенням обох цих опцій. Теоретично міркуючи, в цьому порядку і має зростати швидкодію файлових операцій. Що ж ми бачимо на практиці?

Таблиця. Результати вимірювання (в сек.) Швидкодії файлових операцій в різних файлових системах

тест

Робота з даними

Робота з портами

великий файл

FS + Mode

Copy

Delete

Untar

Copy

Delete

Copy

Delete

UFS, default

211

7

189

255

92

104

0

UFS, noatime

210

7

194

333

99

102

0

UFS, async

211

8

201

352

99

103

0

UFS, both

209

6

202

344

98

103

0

Ext2, FreeBSD

222

25

280

309

222

150

1

Ext2, default

71

6

90

68

7

45

0

Ext2, noatime

73

6

93

68

7

46

0

Ext3, journal

123

6

134

58

6

98

1

Ext3, ordered

81

15

107

115

17

50

16

Ext3, writeback

91

7

107

68

51

53

1

Reiser, default

100

2

59

51

7

44

1

Reiser, noatime

89

2

71

26

7

47

1

XFS, default

95

9

76

83

41

48

0

XFS, noatime

97

9

80

74

42

49

0

JFS, default

132

13

267

160

19

91

0

Результати по копіюванню масиву даних (див. Рис. 1) у всіх чотирьох режимах можна вважати практично ідентичними. Здавалося б, трохи кращі результати дозволяє отримати відмову від поновлення atime, однак і абсолютно, і щодо різниця незначна. І в будь-якому випадку, включення асинхронного режиму не забезпечує ніякого стрибка у швидкодії, якого можна було б очікувати, виходячи із загальних міркувань. Швидкість видалення змішаного масиву файлів також приблизно однакова: кілька кращі результати при включенні обох опцій лежать, швидше за все, в межах помилки експерименту (точність виведення команди date - в межах однієї секунди).

Мал. 1. Робота з масивом змішаних даних

Ще більш вражаючий графік демонструють результати роботи з деревом портів (рис. 2). Теоретично можна було б очікувати різкого стрибка швидкодії при асинхронної обробки величезної кількості дрібних файлів. Однак на практиці ми бачимо прямо протилежну картину: найкращі результати і при розгортанні тарбалла, і при копіюванні дерева портів, і при його видаленні виходять якраз при умолчальне, синхронному для метаданих, режимі. Причому в разі копіювання перевагу його виглядає цілком значущим: включення будь-якої з додаткових опцій (а особливо - їх обох) викликає падіння швидкості цієї операції на 30-50%.

Мал. 2. Робота з деревом портів

Копіювання великого файлу - єдина операція, де умолчальне режим показує як нібито найгірші результати (рис. 3). Однак різниця і в абсолютних величинах, і в відносних виглядає просто сміховинною. І, швидше за все, знову ж таки має причиною природний розкид в межах помилки. Ну а видалення одиничного файлу, як і слід було очікувати, відбувається практично миттєво (хоча, як ми побачимо далі, і це - не саме собою зрозуміле спостереження).

Мал. 3. Робота з великим файлом

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

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

Ext2fs

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

Та ж картина спостерігається в тесті з деревом портів. І розгортання тарбалла, і копіювання каталогу дрібних файлів, і його видалення відбуваються однаково швидко незалежно від того, чи оновлюється час останнього доступу чи ні. Щодо UFS2 це саме «швидко» виражається дво- (для операції «розтарування») і навіть п'яти- (для копіювання) кратним перевагою. Ну а видалення дерева портів взагалі більш ніж на порядок швидше - фактично таке ж швидке, як і видалення змішаного масиву.

При роботі з великим файлом також ніяких несподіванок не спостерігається: копіюється він швидко (більш ніж удвічі швидше, ніж в UFS2), а видаляється практично миттєво.

Загалом, доводиться з сумом констатувати, що в плані швидкодії UFS2 і близько не лежала з ext2fs, чим би це не пояснювалося (desktop-користувачеві ці пояснення за великим рахунком до лампочки). І тому цікаво подивитися, а не виявить себе ext2fs з настільки ж хорошого боку також і під FreeBSD?

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

Звичайно, ext2fs за самою своєю природою не може бути такою ж надійною, як UFS2. І її потенційну схильність до руйнування (а були часи, коли ext2fs майже гарантовано руйнувалася при аварійному завершенні роботи системи) намагається компенсувати настроює її журнальованою, прикручування якої дає самостійну файлову систему - ext3fs. Подивимося, чи дорого доводиться платити за це в плані швидкості.

Ext3fs

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

Питання надійності ми тут не обговорюємо, а ось що стосується швидкодії ... При копіюванні масиву змішаних даних режим journal дійсно виявляється найбільш повільним, проте першість залишається за режимом ordered (а не writeback, як слід було б очікувати). А ось стирання результатів цього копіювання взагалі показує парадоксальну картину: якщо при режимах journal і writeback швидкість видалення каталогу очікувано швидка (практично така ж, як в ext2fs), то в режимі ordered ця процедура виконується просто непристойно повільно (15 секунд проти 6-7, як можна бачити з таблиці).

Розгляд роботи з дрібними файлами залишає дуже суперечливе відчуття. Розгортання архіву - найбільш повільно в режимі повного журналювання, і трохи швидше (і однаково) - в обох режимах журналювання часткового. З копіюванням дерева портів несподівано найкраще справляється режим journal, режим writeback виявляється дещо повільніше, а ordered це завдання просто провалює - швидкість операції видалення виявляється в ньому вдвічі нижче інших.

Далі - більше: графік швидкостей видалення дерева портів просто обернений теоретично очікуваному: блискучий результат в режимі повного журналювання (6 секунд - мало не краще, ніж для ext2fs), посередній (17 секунд) - в режимі ordered, і найгірший для всіх файлових систем Linux (51 секунда) - в нібито якнайшвидшому режимі writeback.

Нарешті, звернення з великим файлом дає нам чергову (вже очікувану) несподіванка: розподіл швидкостей копіювання повторює таке для дерева портів (кращий результат - в режимі ordered, гірше, але близький - в режимі writeback, і істотно гірший - в режимі journal, 50, 53 і 98 секунд, відповідно). Але зате при видаленні цього найбільшого файлу режим ordered відзначився як ніхто: в ньому ця процедура зайняла аж 16 секунд. Не просто гірше всіх, а недосяжно гірше. І ще раз підкреслю, що мова йде не про випадковий сплеск, а про повну загальну середню з трьох вимірів, розділених перемонтування файлової системи.

Як буде видно з подальшого, ext3fs з точки зору швидкодії взагалі виглядає блідо на тлі інших файлових систем, з якими працює Linux. Але проти FreeBSD вона все одно зберігає перевагу по всіх позиціях: зусиллями всіх трьох режимів журналирования початкову ext2fs не вдається звести до рівня частково синхронної UFS2. І навіть найгірший результат ext3fs при роботі з портами залишається недосяжних для тієї ОС, в якій сама ідея портів з'явилася вперше.

Однак, говорячи про портах, я кілька забіг вперед. Тому що спочатку варто було б подивитися, а яка файлова система тримає першість в роботі з великою кількістю маленьких файлів?

ReiserFS

Ця файлова система спочатку проектувалася (в тому числі і) для ефективного поводження з великою кількістю маленьких файлів - зокрема, економії займаного ними простору для. Однак зараз нас цікавить швидкодію - і для всіх файлів взагалі. Так що почнемо з масиву змішаних даних.

І тут ми вперше бачимо торжество теоретичних передбачень: помірне швидкодію при копіюванні нашого масиву в режимі за замовчуванням збільшується на 10% при включенні режиму noatime - зі 100 секунд до 89 (хоча і не досягає рекордного). Але зате рекорд б'є видалення копійованого масиву - по 2 секунди в кожному з режимів.

Дерево портів ... Чудові результати при «розтарування» і копіюванні в умолчальне режимі. При скасуванні поновлення atime в першому випадку вони трохи погіршуються. Але зате - браво - копіювання з цією опцією здійснюється практично вдвічі швидше, ніж без неї; такого результату ми ще не бачили. І знову ReiserFS близький до рекорду при видаленні портового неподобства - фінішуємо голова в голову з ext2fs.

І остання несподіванка від дітища Ханса Райзера - в копіюванні великого файлу воно показує себе в числі кращих, хоча тут вплив noatime і не позначається. Подивимося, чи зможе позмагатися з цим XFS, яка, навпаки, за задумом передбачалася саме для зберігання мультимедійної інформації.

XFS

На масиві даних загального характеру копіювання дає результат, близький до гармонійному середньому, час же видалення їх здається трохи завищеними (9 секунд).

Робота з портами - на середньому рівні по відношенню до «розтарування» і копіювання. І - несподівано великий час видалення дерева портів (більше 40 секунд), що наближається до «анти-рекорду» writeback-режиму ext3fs (хоча все одно багато краще, ніж для UFS2).

А ось результат за великим файлу (48-49 секунд) - не порадував: хоча він і в числі кращих, але від «мультимедійної» файлової системи я очікував більшого. Хоча, може бути, з точки зору SGI, це 700 Мбайт - це аж ніяк не багато? І на втіху - провалу при видаленні великого файлу також не відзначається :-).

JFS

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

• найгірший серед усіх файлових систем Linux результат в копіюванні змішаного масиву і другий з кінця (після провалу ordered-режиму etx2fs) - в його видаленні;
• найгірший результат «розтарування» серед всіх нативних файлових систем взагалі, включаючи UFS2; гіршою виявилася тільки ext2fs з під FreeBSD - але ж з чужака і нічого не візьмеш;
• прямо скажемо, не блискучий час видалення дерева портів;
• копіювання великого файлу - фініш в щільній групі відстаючих.

Загалом, JFS, єдиною з підтримуваних Linux файлових систем, виявилася зіставною з UFS2 по швидкодії (вірніше, відсутності оного). Звичайно, не можна виключити, що знавці її можуть підвищити продуктивність будь-якими опціями; зокрема, я десь чув, що Linux-версія JFS стандартно працює мало не в чисто синхронному режимі - дивлячись на результати, в це цілком можна повірити. Однак, повторюю, за замовчуванням вона постає перед користувачем в якості самої повільної.

Висновки

Повинен сказати, що проведені вимірювання істотно перевернули мої уявлення про файлових системах взагалі (хоча де в чому і зміцнили).

Зокрема, я завжди підозрював, що обидві файлові системи FreeBSD - і стара UFS, і нова UFS2, - поступаюся своїм Linux'овим сестрам у швидкодії. Так це зазвичай видно і, що називається, органолептичним методом. Однак я ніяк не очікував, що для UFS2 в кількісному відношенні відставання виявиться таким істотним. Мушу зауважити - що виконувалися мною раніше вимірювання для UFS просто настільки разючою тормознутости не показували - навіть щодо ext2fs (для ReiserFS менший розрив можна було б пояснити дитячим тоді її віком). Не виключено, що це - розплата і за 64-бітну адресацію, і за вдвічі збільшені inodes ...

Далі, я не очікував настільки гідних результатів ReiserFS не тільки по відношенню до дуже маленьких файлів, але і у всіх інших тестах. Так що беру назад все не дуже хороші слова, які раніше говорив на її адресу. Правда, неперевіреними залишилося емпірично спостерігається (але не підтверджує кількісно) явище падіння її продуктивності на великих (понад 100 Гбайт) розділах, розміщених на програмному RAID - але для багатьох чи desktop-користувачів це актуально?

Чи не показала себе в очікуваному блиску і така улюблена мною раніше XFS. Все ж мало коли доводиться працювати з файлами більше обсягу сідюшнік, а в цих межах вона виявилася не швидше ReiserFS.

А ось у чому вимірювання мене зміцнили - так це в упередженому (і несприятливому) ставленні до ext3fs. І справа навіть не в тому, що хоч якомусь її режим «відзначився» хоча б на одному тесті. Невдоволення викликає саме непередбачуваність її поведінки в залежності від режиму і характеру даних. Ймовірно, розробники мали підстави для висновку про оптимальність режиму ordered - однак ґрунтувалися вони, судячи з усього, на завданнях серверних, але аж ніяк не десктопних.

То яку ж файлову систему вибрати простому настільного користувачеві для своєї окремо взятої персональні виставки? Мій відповідь не буде блищати оригінальністю, якщо я заявлю з усією певністю: кожному овочу - свій фрукт. І марно намагатися знайти систему, однаковий швидку і для зберігання дерева портів (або їх Linux-аналогів), і для складання iso-образів під резервне копіювання, і прочая, і прочая, і прочая.

На щастя, користувач FreeBSD позбавлений цих мук - UFS і UFS2 суть об'єктивні реальності, дані йому у відчуттях беркліанскіх розробників. Тільки він повинен розуміти, що принаймні при роботі з файлами йому доведеться поступитися швидкодією заради стрункості і акуратності використовуваної системи. Втім, не компенсується втрата часу на копіюванні файлів відсутністю поневірянь з розбіжністю версій бібліотек або компіляторів?

А ось користувачеві Linux є над чим поламати голову. Тому що однозначно я не рекомендував би до вживання тільки JFS - та й то, не факт, що, прочитавши багатопудову документацію до неї, я був би таким категоричним (інша справа, що поки жодна з особливостей цієї файлової системи не здатна спонукати мене на таке читання, тим більше по англицкий).

Бо навіть нелюбимої мною ext3fs можна знайти застосування. Зокрема, для кореневої файлової системи в тому випадку, коли з неї в окремі гілки винесені / var, / usr, / opt (якщо в даному дистрибутиві задіюється у реальному часі), і, звичайно ж, / home.

Для перших трьох гілок підходящої бачиться ReiserFS. Особливо якщо у нас - Source Based дистрибутив, який використовує будь-яку портообразную систему. І до речі - ідеальної вона виявиться саме тоді, коли дерево цих портоідов винесено в окрему гілку всередині / usr або / var. А ще вимірювання схилили мене до думки, що і для / home ReiserFS більш ніж придатна - раніше я нічого, крім XFS, в цій якості не визнавав. Хоча і тепер не бачу причин, чому б благородному дону не розміщувати на XFS свої дані - особливо якщо він не має звички часто і у великій кількості їх видаляти.

Нарешті, ext2fs - аж ніяк не найгірший вибір для багатьох користувачів, які не бажають морочитися створенням безлічі розділів і підбором під них ідеальних файлових систем (за умови наявності бесперебойніка, зрозуміло). І вже зовсім незамінною вона виявляється а) для обміну даними з встановленої на тій же машині FreeBSD, і б) для розділу / boot в разі використання мультізагрузчіка GRUB. Так що і стареньку ext2fs рано ще списувати в тираж ...