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!
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.
.3 ms instead of 9 ms, the speed increases are incredible.
ZFS has all the features that btrfs hopes to achieve already, plus major speed increases when using an SSD drive. When you have a read taking place in
My hope is that ZFS can be salvaged after Oracle decides what to do with the opensolaris project. If it's on linux, even better.
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
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.
In humble your opinion, sir?
I not understand do.
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.
Do not question master Yoda!
"Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
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.
Thank you, exacly what I wanted to say. I mean it hasn't been ruled out that the Meerkat CDs will ship on ICMB from South Africa, which is slightly more likely than the CDs shipping with Btrfs as default.
It's on the TODO list apparently:
http://www.linuxfoundation.org/news-media/blogs/browse/2009/06/conversation-chris-mason-btrfs-next-generation-file-system-linux
Why wouldn't you just do your encryption at the block device level using dm-crypt? Then it doesn't matter what filesystem you're using.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
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
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.
Reiser is basically out - it's simply not being developed fast enough to keep up with the curve. EXT 4 seems unstable.
(Just my humble opinion, but I went back to EXT 3 for a complete reinstall of Kubuntu 9.4 after giving it a try for a good 3 months, and I've been installing various Linux's since stormlinux back in 2001. I haven't completely wiped an install (well, not at the cost of losing any data that might have even minimal value at all) and rebuilt from scratch in years, outside of that one case.).
EXT 3 is sufficient for most users needs, probably 90% of users overall, but I have to respect the ones who feel its limits - they are probably right to chafe under them. People do the damnedest things with Linux, and some of those things genuinely need very specific, perhaps idiosyncratic journaling methods, and other specialised file management techniques.
Who is John Cabal?
I think hardware full disk encryption is the only way to go. There's no performance penalty and it's transparent to the OS (which is great for those of us who multiboot). Our experience with PGP and Credant has been horrible, making some laptops unusably slow. Is dm-crypt that much better?
Really? Are we still doing that?
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
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.
1. The file system has the power to brick your machine because of a clock setting
I do not think this word means what you think it means.
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.
Yeah. Not to troll, but if you want to be user-friendly like Windows, you can't dump out to a black screen and tell the user to run some command-line gobbledygook... every 3 months....
Peter predicted that you would "deliberately forget" creation 2000 years ago...
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
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
I find some of the features interesting, but until these problems are solved, I will not try it out.
https://btrfs.wiki.kernel.org/index.php/Gotchas
Yeah, I know, I know, it's a killer file system.
You can't handle the truth.
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...
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Maverick Meerkat will be all about trying out new things, they'll scrap whatever doesn't work.
Funny, that sounds like the last 3 Ubuntu releases to me. Except for the "scrap" part, that is.