[rescue] Linux FSs

[Meelis Roos]

> What does the list think?

Ext3 is my default - it's not the fastest but it's the most dependable 
(and usually not much slower than others). I have not lost any data with 
it other that doing a forced fsck on a mounted FS for my own stupidity 
once. The toolchain is the most tried-and-tested.

I also use XFS sometimes - it used to have trouble sometimes with deep 
call chains and stack overflows (especially on top of RAID + LVM) but it 
should be fixed by now.

Have not really used JFS so I don't have an opinion on that.

Ext2 is only a special-purpose FS - it can lose files on a power failure 
so it's for a fast scratch partition (like for code compilation - code 
itself lives in some SCM) or on slow flash devices etc.

Reiserfs I do not trust - I have even recently come to a machine where 
somebody installed reiserfs on 64-bit system and that was known to cause 
corruption - and it did. Might be finally fixed but it's too late.

Reiser4 never got polised enough to be ready (like degrading performace 
over time and needing a repacker).

There's also Ext4 now (about to be declared not exerimental any more in 
some weeks with 2.6.28 kernel release). I do not consider it stable yet 
(takes at least a year of public testing and bugfixing) but it seems to 
be holding promise: 
http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=1 
Ext4 is an evolutionary change from ext3 - extents, delayed allocation 
etc but no revolutionary changes.

Ext4 is supposed to be a bridge in transition from ext3 to btrfs. Btrfs 
is the next-generation FS designed by Oracle and a former ReiserFS 
developer. Given Sun is clearly not interested in making ZFS work on 
GPL-ed free software projects, the Linux developers considered it to be 
a waste of time trying to reimplement ZFS (and fear for patent 
litigation from Sun) but to implement a 
at-least-as-good-but-hopefully-better filesystem themselves - Btrfs. 
Current development snapshots show it's fast but it's not there yet and 
will not be in the near future.

-- 
Meelis Roos (mroos at linux.ee)