Slashdot Mirror
On the State of Linux File Systems
kev009 writes to recommend his editorial overview of the past, present and future of Linux file systems: ext2, ext3, ReiserFS, XFS, JFS, Reiser4, ext4, Btrfs, and Tux3. "In hindsight it seems somewhat tragic that JFS or even XFS didn't gain the traction that ext3 did to pull us through the 'classic' era, but ext3 has proven very reliable and has received consistent care and feeding to keep it performing decently. ... With ext4 coming out in kernel 2.6.28, we should have a nice holdover until Btrfs or Tux3 begin to stabilize. The Btrfs developers have been working on a development sprint and it is likely that the code will be merged into Linus's kernel within the next cycle or two."
Its a real killer.
zosxavius photography
They'll try to copy the good ideas of ZFS and they will try to avoid the disadvantages (which every software has). So you are never going to have "1 unified filesystem". It's never going to happen. And it's a good thing.
One thing I'd really like is using free space on a raidz(2) as a spare disk.
Imagine the following
10 1TB disks in a raid5/raidz, giving 9TB of space. You are currently using 7TB, this peaks to 8.5TB at the weekend while backups are staged (or whatever).
During the week you have unused space. The file system detects this, and in the background transparently makes a second parity drive out of the spare space, effectively changing to raid6/z2 on the fly.
If you suddenly need to write another 1.5TB, the fake parity is discarded. When your free space drops back below 8TB, the second parity drive is recreated.
If you lose one of your disks with a raid5/z, you in a danger zone until you replace it, and it rebuilds. This way, you are only in a danger zone if you lose the disk at the weekend when you need the extra space -- you can afford to lose another one (your effective free space keeps reducing).
When you put a new drive in, assuming you have the free space originally, there's no rebuild time (your parity already exists).
Another feature would be automatically copying of frequently accessed files -- if a certain bunch of files on a website becomes popular, they would be transparently copied across the spindles to increase access time.
Finally extend the idea of ZFS to a multi-machine cluster, zfs meets lustre.