You are not logged in.
Having a somewhat odd interest in different types of filesystems, I'd thought I'd share this snippet I wondered across.
Brought up on the Fedora development list are the plans for Btrfs in Fedora, which provides a target of Fedora 16 when EXT4 will be replaced by Btrfs as the default Linux file-system on new installations.
Fedora was one of the first distributions to deploy support for installing the Linux distribution to a Btrfs root file-system, while the Moblin/MeeGo camp has already turned to it as the default file-system, and now Fedora may finally have everything ready and are comfortable with the state of this Oracle-sponsored file-system.
With the intended Fedora deployment of Btrfs, they will also switch from using LVM as the disk's volume manager to instead relying upon the volume management abilities built into Fedora itself. Fedora / Red Hat developers have previously already worked on taking advantage of other Btrfs features, like snapshots, to provide system roll-back support by creating a copy-on-write snapshot prior to each yum/RPM package transaction.
In order to meet the Fedora 16 Btrfs target, Btrfs support needs to be merged into Fedora's GRUB package (or a separate non-Btrfs /boot file-system must be used), Red Hat's Anaconda must be hooked in to properly utilize Btrfs and its volume management features, and the Fedora LiveCD must be re-worked a bit to handle Btrfs. Additionally, the fsck support for Btrfs must be completed. Oracle's Chris Mason is nearly (circa 90%) complete with this task.
Before Fedora 16 arrives we still have Fedora 15 to worry about, which will continue to offer Btrfs as a file-system option while EXT4 remains the default.
Canonical is also evaluating when to switch to the Btrfs file-system and we may see that move similarly happen for Ubuntu 11.10.
This would seem to imply that fedora is giving btrfs the big thumbs up! They currently release twice a year, and fedora 15 is (I believe) Due out this May, so it wouldnt be too wrong to surmise that come Christmas btrfs would be the standard install option. However, I have always thought of fedora as being a little bit of a testing bed for red hat enterprise, so reading between the lines, I am thinking they want to release btrfs to the wild, and get the bugs sqwished so it can be incorporated into red hat, which is a good thing all round, for all concerned.
Offline
Interesting, i'm curious though how they will try to improve performance in such a short period of time.
I also wonder why i hear so little about nilfs2 these days as i personally think it might have more interesting design principles than btrfs.
ᶘ ᵒᴥᵒᶅ
Offline
also, obligatory, no fsck until now. i have a bricked hdd sleeping in my office waiting for that since months...
/edit: hmm ah yeah, it's mentioned in TFA
Last edited by bangkok_manouel (2011-03-01 10:27:06)
Offline
also, obligatory, no fsck until now. i have a bricked hdd sleeping in my office waiting for that since months...
/edit: hmm ah yeah, it's mentioned in TFA
There is btrfsck(8). What is wrong with it ?
Offline
bangkok_manouel wrote:also, obligatory, no fsck until now. i have a bricked hdd sleeping in my office waiting for that since months...
/edit: hmm ah yeah, it's mentioned in TFA
There is btrfsck(8). What is wrong with it ?
in short, it shows the problems but it doesn't fix anything. so you can, like me, brick your drive if your file system is damaged.
/edit: typo
/edit2: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready.
source: https://btrfs.wiki.kernel.org/index.php/Main_Page
Last edited by bangkok_manouel (2011-03-01 12:31:18)
Offline
Okay, thanks for the precision. I guess I'll wait a bit more before trying it out then.
Offline
There are, as I understand it, three big issues keeping Btrfs from hitting its final "stable" release:
1) No true fsck (as of November, a fix is due "any time now")
2) The logic used for subvolumes (a sort of "virtual LVM" setup) in Btrfs is wholly different from that used in Ext*, JFS, NTFS, HFS, etc; because of this, there isn't yet a single script/program that will accurately display space consumption. Instead, the user needs to run a couple different commands and extrapolate. A little annoying, but it doesn't affect stability.
3) A bug in the COW aspect of the defrag command which, if run with an incorrect flag, can cause a doubling in the amount of metadata on the filesystem (and thus the amount of space it consumes). Again, it won't wreck anything, but would make management tedious if one needs to restore a snapshot to get rid of extra cruft.
These are all mentioned in the FAQ's on the Btrfs wiki, though the wiki doesn't give priority to any of them. I'm guessing that, if Fedora 16 will be using this later in the year, the Oracle folks have told the Red Hat folks that they're planning on plowing through these issues very soon.
Last edited by ANOKNUSA (2011-03-01 14:55:46)
Offline
Interesting, i'm curious though how they will try to improve performance in such a short period of time.
Yes, the performance isn't good as things stand, but maybe this is too be expected? If they try to patch btrfs for better performance, then releasing a new feature into the code may in some way undo the work they have done. So it would make more sence (at least to me!) To get btrfs out there, finish the full set of features, and then go about improving the performance. I think the feature set of btrfs will be worth the wait, and perhaps even negate the poor performance.
Offline
That is the right point with btrfs, Fruity. Warm up by experimenting with features and overall behaviour today and switch to btrfs if all is OK tomorrow. We are going to choose the best fs more thoroughly in the days ahead...
Our tomcat for your mice! Archlinux for your comps! Alfa Romeo for your roads! Faster running guaranted!
Offline