When the developers of a filesystem state that it is not stable I tend to believe them. From the help text for BTRFS in the kernel configuration:Just got a new SSD for my laptop (the older 40GB SSD simply is to small) and used the chance to give JFS a try on it, hope that works out well, but until now no problems at all.

So do the developers have any word on how long they think this will take? Is it just "we might change the format, possibly in an incompatible way" or is there more to it?

Maybe someone should start another filesystem if btrfs is taking too long and ext4 seems like it is not even designed to work right.

Wouldn't supporting the BTRFS developers be better than to just start from the beginning?

I might give JFS another try on my next install, but for now EXT4 is doing it's job well enough.

BtrFS is no where near complete, and as I said, it's being developed by Oracle as an open source replacement for their version of Oracle-ZFS for their GNU/Linux distribution, not Open-ZFS sponsored by FreeBSD and Illumos. They're basically having to redo Oracle-ZFS from the ground up as a clean-room implementation without reusing any ZFS code at all.

Speaking of alternative file-systems has anyone ever experimented with Reiser4?

No; adding engineers to a project makes it take longer to complete, not shorter.

Does anyone read "The Mythical Man-Month" anymore?

Better yet...

Too many cooks spoil the broth.

I guess sponsoring and donating to btrfs is also a kind of "supporting", which may not add engineers.

So how is xfs compared to ext4? I see benchmarks here showing xfs much slower than ext4. Myself got no time to try yet.

I've tried jfs myself but could not tolerate its extraordinarily long time when handing many small files.

Just about all of them are the same outside a true large server environment, but you might want to be careful with XFS if you lack a UPS Backup unit.

OpenZFS announced a launch today.

ext4 here, no real reason to use anything else, to be honest i've been using extX filesystems since ext2 (ext2, ext3, ext4) and will probably use ext5 when it becomes stable.

OpenZFS sounds promising, though I think it lacks support.

I would say, they have a lot of support... good support:

http://open-zfs.org/wiki/Companies

Illumos has been fostering the ZFS developments for a few years now, and a lot of progress has been made recently in FreeBSD, whereas Oracle refuses to share their code via a loophole within the CDDL license.

If OpenZFS could prove and show Illumos controls the main source tree, and Oracle's implementation uses out-of-tree code, the project could easily be re-licensed under something more GPLv2 friendly, like the MIT license. It wouldn't be perfect, but it would at least allow ZFS to finally be imported within Linux.

Of course the original developers would have to sign off on it, but still there is hope.

For now however, we'll have to settle on ZFSOnLinux, and documentation to effectively deploy it within a Linux distribution is very scarce. I think ArchLinux had a wiki on it though.

I just saw from a web search that the XFS developers refuse to add some option like "data=ordered", and say that "if you want to have that behavior in a shell script, write a wrapper of fsync"!

Am completely taken aback. Does it mean if I distribute a shell script, I have also to distribute the fsync wrapper and a compiler in source code?

Bingo. Welcome to the dark ugly imperfect side of GPL.

It's a sad fact that many GPL projects suffer from the fact developers get egotistical, uncaring, or downright lazy and refuse to listen to their users, and say stuff like, "if you want it, learn C++, and add it in yourself, otherwise, piss off".