Btrfs Could Be the Default File System In Ubuntu Meerkat

An anonymous reader writes "The EXT family of file systems (ext2, ext3, ext4) have ruled many Linux distributions for a long time, and Ubuntu has been no exception. But things may no longer be the same for Ubuntu 10.10 Maverick Meerkat. Canonical's Scott James Remnant said in a blog post that plans are on for doing work to have btrfs as an installation option, and that the possibility of making it the default file system in Ubuntu 10.10 has not been ruled out."

Comments

Hmm... I am going to pass for now on servers...

[ls671]

Hmm... I am going to pass for now on servers. I might try it on desktops/workstations. Not that I use Ubuntu at all. Btrfs is supported by kernel 2.6.32 on other distros as well if you care to configure it properly.

I remember failure stories with other latest and greatest filesystems lately and I will let others continue to test and identify bugs before I use it on servers/SAN with critical data.

From the btrfs wiki https://btrfs.wiki.kernel.org/index.php/Main_Page :

btrfs is a new copy on write filesystem for Linux...

Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes, and many users have been experimenting with Btrfs on their systems with good results. Please email the Btrfs mailing list if you have any problems or questions while using Btrfs.

Re:Hmm... I am going to pass for now on servers...

[jd]

I've run filesystems that were considered ok-but-early-adopter on servers before. Early XFS releases, for example. It's perhaps not really comparable as SGI had already developed XFS v1 on their workstations and so most of the code was fairly heavily-tested before the Linux port of XFS v2. But there's another consideration - if you look at the way btrfs is described, most of the individual components look a lot simpler than are used in other next-gen filesystems. The difference isn't great between, say, a b-tree and a b+tree or a b*tree, and most filesystem coders are well beyond the stage of making errors on simple abstract data types (right?), but simple components assembled in complex ways are generally more trust-worthy than complex components assembled in simple ways.

In fact, going back to the early XFS days (when SGI released Red Hat installers and even a few releases before), I found XFS to be much more stable and much more reliable than reiserfs, even though reiserfs has been around longer and was considered mainstream.

Re:Hmm... I am going to pass for now on servers...

[icebike]

Two is your sample size?

I ran reiser on 108 production servers for years and never lost a byte of data due to the FS. It was robust as hell.

We had two instances where power surges did take down a server all we needed to do was mount the drive in another machine and run reiserfsck. The resize capability was a godsend.

I suggest your problem was somewhere other than Reiserfs.

btrfs may have a better foundation

[thule]

But btrfs may actually have a better foundation than ZFS. When ZFS was first conceived they didn't believe a file system could do btree's and COW. btrfs has proven that it can be done. See the section "btrfs: Pre-history" at:

A short history of btrfs

Re:ZFS comparison

[jtosburn]

I think you don't give quite enough credit to btrfs; it isn't merely a johnny-come-lately, but rather another step forward in filesystem evolution. Try here for a good article on btrfs, by one of the zfs developers, Valerie Aurora. If you like, just skip to the section entitled "btrfs: A brief comparison with ZFS", one flamebait bit of which is this: "In my opinion, the basic architecture of btrfs is more suitable to storage than that of ZFS."

With that said, no one thinks it's ready for critical data storage yet.

Is it better in the recovery department than ext3?

[Enleth]

Personally, I'm using reiserfs (that is, reiser3, not reiser4) solely due to its outstanding disaster recovery capabilities. No matter what happens to the media or the filesystem itself, "reiserfsck --rebuild-tree" is going to bring back everything that was not directly overwritten or corrupted. I've had many things happen to my disks (head crashes, several gigabytes from the beginnig of the partition being overwritten by a borked OS isntaller, "rm -rf blah/ *" instead of "rm -rf blah/*" and so on), and every single time, --rebuild-tree recovered everything that still was there to be recovered. As far as I know, this is due to the fact that all the filesystem metadata is distributed evenly throughout the partition, heavily replicated and identifiable using some kind of magic hashes even when there is no higher-order structure left (so a --rebuild-tree process can just do a linear scan of the damaged partition and find all the "dangling" inodes with ease).

As far as I know, this is not possible (especially using the standard fsck utility as with reiserfs) with the ext* family of filesystems.

So, does btrfs have similar capabilities? If so, I'm going to be quite interested in testing it, even though I'm not using Ubuntu.