Post a Comment
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..
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.
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 24x7, 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.



