Slashdot Mirror
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."
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.
Everything I write is lies, read between the lines.
Making Debian look better with every release!
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.
It’s a tough gauntlet, and it would only made with the knowledge that production servers and desktops can be run on Lucid as a fully supported version of Ubuntu at the same time. I’d give it a 1-in-5 chance.
There are quite a few pre-conditions for it to be made alpha, so it is not as likely as the summary makes it out to be.
The main Btrfs features include:
Extent based file storage (2^64 max file size)
Space efficient packing of small files
Space efficient indexed directories
Dynamic inode allocation
Writable snapshots
Subvolumes (separate internal filesystem roots)
Object level mirroring and striping
Checksums on data and metadata (multiple algorithms available)
Compression
Integrated multiple device support, with several raid algorithms
Online filesystem check
Very fast offline filesystem check
Efficient incremental backup and FS mirroring
Online filesystem defragmentation
Currently the code is in an early implementation phase, and not all of these have yet been implemented. See the Development timeline for detailed release plans.
https://btrfs.wiki.kernel.org/index.php/Main_Page
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
You can't compare it to Reiser4. Reiser just kills everything out there.
Are you certain that it's due to FS corruption? I've had ext4 fail to boot due to silly errors like the last write being one hour into the future (some kind of time zone confusion), but no corruption at all. I ask only because most people seem incapable of reading an error message and just doing the /sbin/fsck.ext4 /dev/sdaX that it explicitly calls for.
Alternately, you could consider using ZFS if you can live with the uncertainty of the opensolaris project. The major plus is that all the functionality is already there.
Don't forget that FreeBSD has a native implementation of ZFS as well. (You can also get ZFS for FUSE, but as such it's probably not suited for a main file system.)
ZFS is also available in FreeBSD 7.0 and later. It's even marked as "production quality" in FreeBSD 8.0 and later.
It's a few versions behind (ZFSv14) OpenSolaris (ZFSv24), but on par with Solaris 10 (ZFSv15). FreeBSD 8.1 should have ZFSv15 in it by the time it's released this summer. And there's work ongoing to bring ZFSv20-something into 9.0.
Btrfs will be the default filesystem for MeeGo:
http://article.gmane.org/gmane.comp.handhelds.meego.devel/1510
Reiser is a killer FS, but you have to keep your eyes on it...it totally chokes under certain conditions, with the result being your system gets locked up.
regardless of why, I've never heard of that happen with an ext3 filesystem. Now imagine you're running a server, a trip to the datacentre to run fsck would be annoying.
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
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.
This is a filesystem, where the developers keep finding major (including fatal) bugs basically every other week. If even the slightest idea of making it the default filesystem in a distribution scheduled for release in 6 months crosses your mind, seek professional help. Now.
Really? Are we still doing that?
...except it's not production quality. Please skim the past 6-8 months of posts to the freebsd-fs and freebsd-stable lists: you'll be surprised at the number of error reports.
Booting from a ZFS pool on FreeBSD is also somewhat broken; users are still reporting issues with it, and booting from raidz still doesn't appear possible. Supposedly booting from a ZFS mirror works.
Simply put: if you want to use ZFS and expect stability, run OpenSolaris or Solaris 10.
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.
This is Slashdot. Common sense is futile. You will be modded down.
Obviously, Btrfs also does volume management without LVM. It even manages to do better than ZFS in some areas, for example Btrfs can reduce the pool capacity easily thanks to back references (a new and cool fs technique which is being incorporated to Btrfs), whereas ZFS still can't reduce the capacity of a pool and it will take a lot of complexity to implement it (you really should read the link)
Or you can run FreeBSD 8, which has ZFS and has had DTrace for a while now.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
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.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
When 900 years old you reach, use ext2 you will not! Hmph!
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
FreeBSD 8-STABLE is now at zfs pool version 14 and you can now boot from zfs directly if you wish so. I don't because, well I use full disk encryption with geli so I need a separate boot partition anyway. And though my laptop indeed have 4GB of memory, I still have 2.5GB free after a few hours of using Gnome, Firefox, Thunderbird, PostgreSQL and a bunch of xterm... Although I use usb keys, webcam, mouse, printer, I don't have any usb related problems so I guess I'm just lucky.
All in all, it beats the crap out of using Linux with ext2/3/4 and LVM. Try to use snapshots on LVM and you'll quickly find why it's a bad idea. The good news is that with btrfs, Linux may catch up to where FreeBSD is now in 2-3 years time.
Oh, by the way, as an added bonus you completely avoid the clusterfuck of alsa/pulseaudio...
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)
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50