Думаю, каждого, кто начинал знакомство с 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 даже существуют средства, позволяющие это сделать.
Однако, как и всякая легенда, эта лишь производит впечатление достоверности. Во-первых, безвозвратная потеря данных относится лишь к очень маленьким файлам. Среди пользовательских таковых практически не бывает, а все прочие же легко восстанавливаются из дистрибутива.