Btrfs Could Be the Default File System In Ubuntu Meerkat 269
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."
Hmm... I am going to pass for now on servers... (Score:5, Interesting)
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 [kernel.org] :
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:please... (Score:4, Interesting)
Btfrs already seems to be more stable than ext4: every PC I own with an ext4 partition has failed to boot at some point due to disk corruption, whereas the one with an Btfrs partition has worked fine for the few months since I configured it. I eventually turned on data journaling to try to stop ext4 corrupting disks and so far that's been safe but largely because it's eliminated all the supposed performance benefits of ext4.
btrfs may have a better foundation (Score:5, Interesting)
A short history of btrfs [lwn.net]
Re:ZFS comparison (Score:5, Interesting)
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 [lwn.net] 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.
Re:Encryption? (Score:3, Interesting)
Re:Hmm... I am going to pass for now on servers... (Score:5, Interesting)
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.
volume management (Score:2, Interesting)
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 [lwn.net]
And ZFS incorporates volume management, so no more pvcreate/vgcreate/lvcreate rigamarole; and LVM doesn't even give you mirroring/RAID--you have you have to use a completely different software stack for that.
You can have your b-trees, I'll take my "zpool create <mirror|raidz[1-3]> <devs>", thanks. "zfs send/recv" is also awesome.
Just waiting for built-in crypto and "bp rewrite" now, but otherwise I've been happily using ZFS in production for a few years.
Is it better in the recovery department than ext3? (Score:5, Interesting)
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.
Re:Ubuntu... (Score:3, Interesting)
'Usability'? As far as I can tell, Ubuntu doesn't give a damn about usability, or they wouldn't have broken wireless on *both* the last two releases (10.04, anyone using a rt2870 based card on a WPA2 network was out of luck, 9.10, anyone using a WPA2 network period (or was that WPA at all? I can't remember) was out of luck, because the version of NetworkManager forcibly installed (never mind that the copy of wicd I had installed worked fine, Ubuntu knew what I needed better than I did, so it helpfully uninstalled it) couldn't handle it).
I've run Debian *unstable* on my server for the last decade or so, and I've never had this kind of problem.
Re:ZFS comparison (Score:4, Interesting)
Despite FreeBSD now having version 13 implementation of ZFS in 7.3 and 8.0 RELEASE, it's still a complete gongshow. (I'd argue that's largely the case with FreeBSD methods in general - lacking "best practices" and all that, but I'm sure I'd get flamed.)
In the 7.x releases, there's support for ZFS. It works, mostly, with some cryptic kernel loader configuration changes to set memory allocation and the like - provided you've got at least 4GB of RAM. Otherwise, expect instability and file loss.
In 8.0 RELEASE, this situation has been much improved. Except there's still no ability to boot from ZFS directly, and so you're stuck with a half-assed kludge. The workable technique of booting from USB devices in 7.x no longer is on account of the "new and improved" USB stack which uh, isn't improved on account of it barely ever working properly (storage doesn't get recognized, devices falling off the bus, little stuff). Oh yeah, and the "needs 4GB of RAM, or else" issue is still there, though in light of everything else is relatively minor.
Re:Is it better in the recovery department than ex (Score:4, Interesting)
I used to run Reiserfs after having a VERY bad experience with EXT3, but I've since switched back to EXT3 now that it's a lot more mature.
What did I like about Reiser? Exactly as you described; I never saw --rebuilt-tree fail. I've had NTFS and EXT2 and EXT3 partitions go bad but I have never had a ReiserFS partition become unrecoverable; if the drive spun up and could be enumerated by the OS, reiserfsck could retrieve everything even if it appeared lost. I also really liked the zero-slack feature (no wasted disk space!)
Why did I finally abandon ship?
Honestly, it was performance.
Writes are fast under reiser -- VERY fast. It is super reliable - I've never expected any filesystem to be so resilient.
What was wrong with it then?
Deletes. Deletions take for-freaking-ever. Right-click a file on a reiserfs partition in konqueror, and wait and wait and wait (watch the minute hand move on a clock or watch!) for the context menu. Delete a folder containing 70K files? Start the delete, come back an hour later, and see the deletion is still going. It is dreadfully slow deleting files. Do the same to an EXT3 (or now, EXT4) partition, an XFS partition, or even NTFS (via NTFS-3G) partition, and the deletion will take seconds - or maybe a minute for really immense directories. Reiser? s. . . . l. . . . o. . . . .w. . . that was honestly the only thing I could find wrong with Reiser (the FS, obviously, not the mama-killing douche of a meatbag who is hopefully being raped and beat up daily)
Re:Hmm... I am going to pass for now on servers... (Score:5, Interesting)
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.
Re:Meego is Switching (Score:1, Interesting)
Not really switching: Moblin has been using btrfs for more ~6 months already.
Re:ZFS comparison (Score:1, Interesting)
I'm running a 4TB zpool on FreeBSD 8.0-STABLE with 1.5GB ram on x86 (32-bit). I've tweaked some kernel parameters but it's stable.
Filesystem safety (Score:3, Interesting)
I agree that reiserfs has issues, having lost a few filesystems that way. Filesystem integrity is not something calculated from how long the system is marked production or even how stable some find it. We need better tools to stress filesystems so we can quantifiably measure safety for specific types of work. (I expect different results for different conditions, since some find reiserfs works for them.) Just as well Slashdotters are so good at causing stress...