Думаю, каждого, кто начинал знакомство с Linux’ом во времена безраздельного господства файловой системы FAT в DOS/Windows, ext2fs поражала скоростью выполнения всех файловых операций. Что было обусловлено эффективностью их кэширования и полностью асинхронным режимом работы. За что, как уже только что было сказано, приходилось платить надёжностью – сбой системы по любой причине влёк за собой тяжкие последствия, вплоть до полного разрушения файловой структуры. Но и даже когда до полной катастрофы дело не доходило, отказы (например, по питанию) вызывали за собой долгую и нудную процедуру проверки целостности файловой системы.

Для решения проблемы надёжности файловой системы (они, хотя и в различной степени, касались всех UNIX'ов) предлагались различные механизмы – Soft Updates, о котором только что говорилось, был одним из них. Однако магистральная линия развития файловых систем пошла по пути так называемого журналирования. Суть его в том, что сведения о файловых операциях записываются в специальный файл журнала до того, как эти операции будут фактически выполнены. Это дает возможность после любого сбоя «откатить» файловую систему до последнего непротиворечивого состояния. Оборотной стороной чего, как обычно, яв.ляется снижение быстродействия – различное для отдельных файловых систем и видов файловых операций.

Эпонимом журналируемых файловых систем стала JFS, разработанная IBM для собственных RISC-станций и своего же варианта UNIX — AIX (1990-й год). Затем, в варианте JFS2, она была портирована сначала на серверную версию OS/2 (конец 90-х годов), бившуюся тогда в последней стадии агонии, а вслед за тем — и на Linux, разумеется. Где она и прижилась под именем просто JFS. И стала, кажется, первой «чужой, но породнившейся» файловой системой, поддержка которой была официально включена в каноническую версию ядра — точной даты не помню, но где-то аккурат рядом с рубежом тысячелетий.

Однако широкого признания Linux-реализация JFS не снискала – ни тогда, ни в последствии. В частности, и вследствие исключительной медлительности – в этом отношении она могла поспорить только с UFS2 из FreeBSD. Причина заключалась в том, что в Linux-версии разработчики отказались от собственного кеширования файловых операций (наличествовавшего в реализациях JFS для AIX и OS/2), положившись на то, что эта функция будет выполняться ядром.

Следующей журналируемой файловой системой в Linux стала ReiserFS, разрабатывавшаяся специально для этой ОС Хансом Рейзером (Hans Reiser) и сотрудниками его фирмы Namesys, начиная с конца 90-х годов. Официальную поддержку в каноническом ядре она обрела с выходом его версии 2.4.

Коньком ReiserFS (кроме собственно журналирования) была работа с очень большими массивами очень маленьких файлов – то есть файлами меньше логического блока файловой системы (обычно в диапазоне от 512 байт до 4 Кбайт). А таких в любой UNIX-системе действительно несчётное множество. Типичный пример – дерево портов FreeBSD или портежей Gentoo.

В большинстве файловых систем для таких мини-файлов существует как свой inode (информационный узел, содержащий метаинформацию о файле), так и блок данных, что приводит как к расходу дискового пространства, так и снижению быстродействия файловых операций. В частности, именно в этом причина катастрофической задумчивости файловой системы FreeBSD (как старой, UFS, так и новой, UFS2) при работе с собственной же системой портов.

В файловой системе ReiserFS в таких случаях отдельные блоки под данные не выделяются -- она умудряется запихать данные файла непосредственно в область его же inode. За счет этого и дисковое пространство экономится, и быстродействие возрастает -- буквально в несколько раз по сравнению со всеми прочими файловыми системами. Повторяю, речь идёт сейчас только об операциях с очень маленькими файлами – на всех прочих такого превосходства, разумеется, нет и близко.

Такое обращение с мелкими файлами ReiserFS послужило причиной возникновения легенды о ее ненадежности. Ибо при крахе файловой системы (то есть разрушении служебных областей) данные, размещенные совместно со своими inodes, вместе с ними же и пропадают -- причем безвозвратно. Тогда как в тех файловых системах, где inodes и блоки данных всегда разобщены в разных областях дискового пространства, данные теоретически можно восстановить. Так, для ext2/ext3 даже существуют средства, позволяющие это сделать.

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

Во-вторых, говоря о возможности восстановления данных из блоков, утративших привязку к своим inodes, я не случайно употребил определение «теоретическая». Потому что на практике это занятие чрезвычайно трудоемкое, не дающее гарантированного результата. Каждый, кому приходилось этим заниматься, согласится, что предаться ему можно только от полной безысходности. И это относится ко всем файловым системам Linux. Так что этим аспектом при выборе файловой системы можно пренебречь.

По суммарному быстродействию ReiserFS была однозначно быстрее всех остальных одновозрастных ей журналируемых файловых систем, а по некоторым показателям могла с успехом потягаться и с ext2, бывшей тогда эталоном быстродействия.

Что же до надёжности – повторяю, панические слухи на этот счёт не имели под собой оснований. В тестах на отключение питания (а во времена её становления я такие тесты проводил регулярно, и не для развлечения – таковы были мои тогдашние жизненные условия) она вела себя ничуть не хуже любых других журналируемых файловых систем.

Главная же проблема ReiserFS была в другом – в совместимости. Сначала она «из коробки» поддерживалась очень малым количеством дистрибутивов, и совсем не поддерживалась никакими другими ОС, даже соплеменными BSD. Только в DragonFly довольно быстро реализовали модуль её поддержки в режиме «только для чтения» – но отношение этой операционки к другим файловым системам всегда было особым.

Проблема с совместимостью для ReiserFS возникла и в последние годы. Если раньше она «ещё не поддерживалась» многими дистрибутивами, то теперь один за зругим дистрибутивы её «уже не поддерживают». Видимо, скоро она исчезнет и из ядра Linux'а.

Чтобы более не возвращаться к этому вопросу, замечу, что на протяжении ряда лет Ханс Рейзер и фирма Namesis разрабатывали файловую систему Reiser4. Это не была очередная версия ReiserFS (развитие той остановилось на версии 3.6.X), а существенно новая разработка, в детали которой вдаваться сейчас не буду: до полной пригодности к практическому применению она доведена не была, и теперь уже, наверное, никогда не будет. О некоторых причинах можно догадаться, прочитав соответствующий раздел в книге Мир FOSS. Заметки гуманитария, имеющей место быть в Библиотеке Блогосайта.

Зато идеалом с точки зрения совместимости оказалась ext3fs – журналируемая модификация классической ext2: представленная на рубеже тысячелетий Стивеном Твиди (Stephen Tweedie), она, однако, получила поддержку в ядре Linux'а не сразу, а даже позже, чем ReiserFS. Однако после этого была включена практически во все дистрибутивы и, следовательно, могла быть прочитана почти на любой Linux-машине. Более того, она осталась полностью совместимой с ext2 по формату. То есть прародительница превращалась в ext3 лёгким движением руки – точнее, добавлением к ней журнала с помощью утилиты tune2fs не только без остановки машины, но даже без отмонтирования целевого носителя. Не менее проста была и обратная процедура – ext3 можно было просто перемонтировать без журналирования, и тогда она становилась самой обычной ext2. Утилиты для работы файловой системой (создания, проверки и так далее) для ext2 и ext3 также были одними и теми же.

В ext3 (и это была её особенность) предусматривалось три режима работы: