Filesystems are dead, or should die
Posted Sep 22, 2005 18:43 UTC (Thu) by eff-tech
Parent article: Reiser4 and kernel inclusion
Feature-rich filesystems are complex, and complexity is the last thing you want in such a crucial component. Even a relatively simple filesystem like ext3 went bad a few versions ago when you had an SMP system. (They fixed it, but still.) Furthermore, spiffy filesystem features like versioning (VMS), multiple streams (NTFS, HPFS, HFS(+)), encryption (EFS, cryptoloop), extended attributes (ext2/3, BFS), ACLs, and so on, are not portable and are often unused because of that non-portability and/or because of the unnecessary development and operational complexity they introduce.
For example, does anyone use NTFS' multiple streams feature, except to hide malware? HFS+'s multiple streams just cause pain when e.g. backing a Mac up to a Linux server. Metadata indexing such as in BFS was nice, but insufficient -- we want full-text indexing now, and the kernel is no place for such complicated code. Extended metadata is a losing strategy anyway.
Reiser is supposedly fast, and so is ext2/3, but it doesn't matter. There is no universally fast filesystem; a speed gain for one task is often offset by a speed loss for another task. If you need speed, you need many fast spindles. The noatime mount option is good (that noatime is an option at all is another argument against features!). If you have a trustworthy UPS, you can consider the async option.
The thing to do, if you insist on having a filesystem at all, is to make it as simple and safe as possible, and to provide a mechanism for user code to be called when certain filesystem events happen -- push the complexity out to userland. Some Linux systems come with a daemon that monitors filesystem updates, so that it can keep its own data structures updated (e.g. a full-text index).
Even better, though, is to just get rid of filesystems. See EROS and Coyotos.
I'm not so much against ReiserFS per se, as I am against creeping featurism.
to post comments)