Slashdot Mirror
Fedora 16 To Use Btrfs Filesystem By Default
dkd903 writes "According to proposals for Fedora 16, Btrfs will be the default filesystem used in that release. The proposal has been approved by the Fedora Engineering Steering Committee. In Fedora 16, the switch from EXT4 to Btrfs will be a 'simple switch' — it means that major Btrfs features such as RAID and LVM capabilities will not be forced onto users."
Can't wait to turn all my files into butter.
Oh wait... I'm a dummy that can't read.
Summary: We like it when you test new stuff for us, and our customers are clamoring for this filesystem in RHEL, so we're going to let you try it out on Fedora for a while and experience the hiccoughs. And speaking of new stuff, we're going to finally get around to moving up to grub2 like everyone else, which we haven't bothered to implement even though it's much better, and we allegedly like new stuff.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Surely there could be a better source for this than one blog post (I know, high UID so I must be new here.)
But linking to something like http://fedoraproject.org/wiki/Features/F16BtrfsDefaultFs or http://thread.gmane.org/gmane.linux.redhat.fedora.devel/149196/focus%3D149215 to lend a little authority might have been nice...
In the long run btrfs will be good to have, especially with solid state drives gaining popularity. Even embedded devices can easily have multi-gigabyte flash chips, and btrfs would be faster and more efficient on these when compared to jffs2 and yaffs.
It makes perfect sense. Btrfs won't get stable for RHEL unless it's beta tested in Fedora first.
For some reason I'm getting really low performance on btrfs, both on a single disk and on raid1 configurations. I have tried with -nodatacow and with and without -compress, but it seems it doesn't have any effect. Also, I have 90 gigabytes of free space on Storage1 but I get drive full error when I try to write there. Rebalancing it didn't fix the issue. The btrfs command-line tool is, well, rather incomplete and somewhat buggy, like e.g. when I query 'btrfs fi df /media/Storage2' -- with Storage2 being the raid1 pool -- it reports the size and usage of the smallest disk on it, not the whole thing. I don't understand why. I also have had some filesystem corruption which caused me to lose quite a bit of data, and again the only way to fix it was rebalancing the whole thing which takes the whole damn day.
I do understand that it's a filesystem that's still under development, but the tools atleast need a lot more work. They're just too incomplete at the moment. I'm not really sure pushing it as the default filesystem for end-users is a good idea yet.
Pretty sure default filesystem != mandatory. They're not going to suddenly drop support for ext*.
No, but you may have to know how to get it.
If you install from a LiveCD, which is the default method of install, and the only one you'll see unless you dive deep down on the Fedora site, you have to use the file system they give you. You can change partitioning and much else, but not the file system type. If you do, the installation will fail, telling you that you have to use the same file system as the CD image.
To get an image that lets you choose the file system without erroring out if you do, you have to (at present):
- Instead of "Download Now", click "More option"
- Instead of one of the many options listed there, click "All download methods" hidden on the bottom right.
- Choose one of the packages under "Install Media" section.
If you don't, you can, at present, choose any file system you want, as long as it's ext4. Presumably, with F16, it will be btrfs.
This jumping through hoops seems to be deliberate by Fedora to get people to not use the full install DVDs, but install through a LiveCD instead.
As I need extended metadata support for Samba to support full CIFS compatibility including advanced permissions, there's really only one performance file system to choose: xfs
Btrfs won't be touching my machines until it's forked away from Oracle.
The fact that you don't see how a filesystem integrated snapshot function could make a difference tells me that you've never used anything like that. And your alternative of managing partitions and 'backups' tell me that you certainly have never tried to manage anything like this on a scale beyond your own machines.
Let me tell you, ZFS-like snapshots are the best improvement to computing since proper multi-user systems. It makes managing file security and integrity so, so much easier, and at almost no cost. (and by ZFS-like I mean with the ease and speed of ZFS, I've not yet seen much numbers on BTRFS performance)
Snapshot takes minimal disk space compared to a backup. Plus you would need to backup the entire / tree to rollback changes made by a yum update.
Much like ZFS, mdadm will simply be replaced with another set of commands. If a drive crashes and the array is not correctly set up, you will also lose data and it will be a pain in the butt to repair it (I've done ZFS recovery of a corrupted pool, no fun). Again, RAID (or any software checksum based alternative) is not a backup. You should have hourly/daily/weekly snapshots and backups depending on the importance of your data.
The good thing about ZFS and Btrfs vs RAID is that they fail graciously. Most of the time it will be able to indicate which files are corrupt, allow you to mount read only and at least copy portions of it over so there is some more intelligence built-in than a simple XOR but that's just the progression of technology.
Custom electronics and digital signage for your business: www.evcircuits.com
...Btrfs is currently under heavy development, and not suitable for any uses other than benchmarking and review.
That sure limits the uses of a default Fedora installation.
I think the bigger issue with btrfs vs mdadm and ext4 will just be maturity. Btrfs repair tools just haven't evolved to the same place the other tools are at, but there is no fundamental reason why they won't eventually make it there.
As you say btrfs has the advantage that it knows something about how the space is used, so if space was just free it could just nuke it and not worry about trying to salvage garbage data. It could also use free space to leverage recovery. And, the concept of COW means that strips are less likely to be in a transitory state of having meaningful data partially overwritten by other meaningful data, since the filesystem would first try to write the stripe over unused space leaving a fully intact backup if it is interrupted and the array is already degraded/etc.
The last time I tried test-converting an existing ext4 into a btrfs on RAID it paniced, but it has been almost a year now...
I'd like to see btrfs implement a proper block tiering system. They're doing something for storing "hot" blocks on SSD, but what about giving us the full monty? Where I can rank storage types myself, assigning a different cost to each type. Hotest blocks in RAMdrive (battery backed of course), next step down fast SSD and then slower SSD, followed by Fibre, SAS, SATA and finally tape. Yes tape. Just create snapshots as backups. These blocks then sit there and drift down to tape storage when required.
Funny how this has all been done before when disks were really slow. I suppose it's the big gap of incredibly fast SSD's (compared to mechanical) that's resurrecting these ideas. With this done, btrfs could be stuck in as a relatively cheap SAN/NAS solution. All done in a big tower case in my loft.
There was already a yum plugin for this (yum-plugin-fs-shapshot) as far back as F13 as mentioned here: http://fedoraproject.org/wiki/Btrfs_in_Fedora_13
It will do an automatic btrfs snapshot of affected filesystems before every yum transaction so that you can go back to whatever point you want. Also, since it is partition dependent, you can rollback your system partition and not undo changes you may have made to your home directories if you have those on different partitions.
btrfs is quite powerful but I have found that the user/GUI tools have not come up to speed yet. I have been using btrfs from my F15 netbook and it seems to have caused no issues so far. However, enabling transparent compression and any tweaking has entailed editing /etc/fstab (never a thing to do lightly) and command lines.
Hopefully some of the GUI disk management tools will start to make available some of the capabilities of btrfs.
Use an incremental backup?
That would still mean a shitload of data to copy around. The point of copy-on-write snapshots is that the cost of copying your whole file system is essentially zero.
To make an normal application analogy: Of course you don't really need Undo/Redo, you can just "Save As" your file at any step of the way, but Undo/Redo makes things a hell of a lot more convenient and more importantly it helps you in those situation where you would have considered a "Save As" to be to much work to bother with and thus have no backup to fall back to.
ZFS still has a lot btrfs doesn't:
64 bit CRC support so disk corruption is caught.
RAID 5/6
Block level deduplication
Encryption
ZFS also replaces the LVM layer, making write performance on raid-Z a lot better than a filesystem + LVM layer.
This isn't to say btrfs is bad, but until dedupe is added, it will be a generation behind the competition.
Thanks for the correction, as that definitely is a notable difference.
Now, if we can get a filesystem that supports autotiering (where it knows which array is SSD, which is spindles and places data accordingly due to times accessed), that would be great. Outside of EMC's offerings, I don't know any really available.