Submitted by Valerie Aurora has published a great article in LWN about btrfs: “You probably have heard of the cool new kid on the file system block – after all, Linus Torvalds is using it as his root file system on one of his laptops. But you might not know much about it beyond a few high-level keywords – copy-on-write, checksums, writable snapshots – and a few sensational rumors and stories – the Phoronix benchmarks, btrfs is a ZFS ripoff, btrfs is a secret plan for Oracle domination of Linux, etc. When it comes to file systems, it’s hard to tell truth from rumor from vile slander. In this article, we’ll take a behind-the-scenes look at the design and development of btrfs on many levels.”
I am really looking forward to BtrFS. I should enable Time Sliders in Nautilus/Dolphin and other cool stuff. Snapshots could be used by the package management. I would also love to have compression.
PS.
I really hope that it will be renamed BetterFS once it is stable.
I agree, it’s a bit too “geeky” for a mainstream use name 😉
BetterFS (or ButterFS – lol) is a terrible name for the OS.
It’s like adding “new” to something. At some point something comes along that is newer. At some point something will come along that is “better”…
Better is a relative term. I would just have to come out with BestOS 🙂
I think LG’s “Life’s Good” catch phrase has similar problems. I’d love someone to come out with “Life’s Great”.
Oh, I don’t have any better suggestions though…
BetterFS (or ButterFS – lol) is a terrible name for the OS.
It is not an OS… It is a filesystem.
For a filesystem BtrFS is perfectly suitable; no Joe User will care what filesystem they use or what’s its name, and system admins and geeks actually understand the idea behind that name..
Yeah, they should have gone for either the full expansion BTreeFS, or the more proper abbreviation BTFS. BTrFS or BtrFS just looks weird, and is pronounced even weirder.
But, it’s too late for that. And besides, what’s in a name?
However, it would be nice to see the same kind of overview of the device management level, and how that compares/contrasts to device management in ZFS.
With ZFS, things are nice and simple and separate from the filesystem. Use “zpool” to create storage pools, create vdevs out of multiple disks, and add vdevs to pools. Use “zfs” to create storage volumes and filesystems.
At first glance, with BtrFS, everything is munged into the FS. For example, you use the same command to manage disks as you do for creating filesytems (mkfs.btrfs). And it seems that the disks are dedicated to that one filesystem.
I haven’t, yet, found a more in-depth look into how BtrFS manages disks, and how that fits into the rest of the Linux storage stack.
Btrfs can handle multiple devices and create filesystems out of the pool space, and use different mirroring/stripping policies. You can see the internal details of it here http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support .
You won’t guess it from the LWN article linked because all the multidevice/mirroring/stripping thing is not done at that level. The root btree has not knowledge of that. It’s the chunk tree (which is just another btree, but using different keys) where “chunks” (big portions of data allocated from the device allocation tree, and from where the extent tree allocates space) store their mirror/strip configurations.
You don’t use the same tool to create filesystems and to manage them. You can create them with mkfs, and you “manage” them with btrfsctl and btrfs-vol. Yes, ZFS command line tool is nice, but for btrfs it’d just a matter of creating a readline program. It’s not exactly the most critical issue in btrfs now.
For those of you who just want a quick summary:
btrfs = placental mouse
ZFS = marsupial mouse
My thoughts? What does that make a stuffed toy mouse? vfat? Reiser? something in between?
VFAT definitely is a zombie mouse, no doubt about that.
Died some years ago, but still haunts us with dead eyes and muttering of the words “patentsssss, precioussssss patentssss’.
and is about the fastest and most efficient filesystem out there for use on USB flash keys. Its simplicity works in its favor in that case. And the difference is noticeable in actual use, and not just in benchmark numbers.
Good article… I skipped over some of the technicals.
I have to say… when I compiled the kernel for my sheevaplug a couple of days ago I was very tempted to add btrfs support.
Maybe I’ll recompile and add the support. I have two external 1Tb hard drives. One will be up 24×7, the other will come online every once in a while for an rsync then get unplugged and put back in the safe.
Obviously the offline backup one would use something like ext3 rather than btrfs.
I have read recommendations of using more than one type of filesystem for your live data and your offline data anyway… one of them might as well be btrfs.