При всех немерянных достоинствах 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 Гбайт оперативной памяти (2x512 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 рано еще списывать в тираж...
Сообщения
