Filesystems are dead, or should die

Posted Sep 22, 2005 18:43 UTC (Thu) by eff-tech (guest, #32417)
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

Filesystems are dead, or should die

Posted Sep 23, 2005 11:39 UTC (Fri) by job (guest, #670) [Link]

"Feature rich" is not a one dimentional variable. One might consider the Plan 9 file system to be very feature rich, i.e. you can do a lot of stuff with it that you can't do with POSIX file systems. But it achieves this in the fine tradition of being composed of very well defined extremely simple components.

I don't think portability is a goal in itself. It is good to achieve whenever possible, but must not reduce systems to their least common denominator. There must also be room for new developments. On the other hand, if you think of pure research systems such as EROS as even better, we probably agree on this point anyway.

Filesystems are dead, or should die

Posted Sep 24, 2005 1:49 UTC (Sat) by abartlet (subscriber, #3928) [Link]

> For example, does anyone use NTFS' multiple streams feature, except to hide malware?

Unfortunetly yes, and this is becoming a bigger and bigger problem for Samba. As Win9X moves out of production, and applications begin to depend on NTFS, the named streams are 'just too useful'. They currently include biographical details in MS office, and as faw as we can tell will include even more in future.

The main things stopping this is traditions with e-mail and the FTP backup example described earlier. However, we expect this to be a genuine requirement from Windows clients in the future.

Andrew Bartlett
Samba Team

Filesystems are dead, or should die

Posted Oct 1, 2005 21:01 UTC (Sat) by renox (guest, #23785) [Link]

> 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

Funny advice that, we all know that journaling adds complexity to a FS, so safe and simple are conflicting options.

>Even better, though, is to just get rid of filesystems. See EROS and Coyotos.

Better in which sense?
In a paper on EROS, I've read that the main reason that EROS is bigger than L4 is because of its single storage mechanism.