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.
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.
Yeah, stupid ubuntu for trying to incorporate usability features into Linux. How's a linux user supposed to retain their air of smug supperiority if the average schmoe can install it. At least I have my HC11 microcontroller and assembly code to fall back on!
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.
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.
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.
You can keep your ugly old broad. Me, I want something young and fresh, even if she's a little loopy.
Loopy chicks fsck better.
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.
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)
How's a linux user supposed to retain their air of smug supperiority if the average schmoe can install it.
Become a FreeBSD user, of course. Or was that a rhetorical question? Have you ever met a FreeBSD user?
~/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
You can keep your ugly old broad. Me, I want something young and fresh, even if she's a little loopy.
Loopy chicks fsck better.
And you can mount them more times in a row. Loopback mounting, even.
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009