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."
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...
It makes perfect sense. Btrfs won't get stable for RHEL unless it's beta tested in Fedora first.
It seems like they haven't: https://btrfs.wiki.kernel.org/index.php/FAQ#When_will_Btrfs_have_a_fsck_like_tool
Hopefully they know something about it being released soon since making the decision to use it.
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
It says right here on the btrfs wiki: "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. "
So I'd say yah, that's a pretty important piece to be missing if you're talking about making it the default for a distro, even one as free-wheeling as Fedor.
So, I'm a Gentoo Dev and I'd qualify that statement a little. Gentoo tends to make a lot of stuff available very early, but it doesn't tend to go all-in with experimental stuff for the base user experience. The default Gentoo stable experience is legacy Grub, for example. And Gentoo hasn't bought into Unity/Systemd/etc. Although, there is talk of adding systemd to the list, and Chrome OS is a Gentoo-based distro that uses unity - so clearly it can be done.
Gentoo tends to be about giving users a default experience that is reasonably stable, but making it a lot easier for users to branch out and try different things, while still keeping much of the update automation in place.
Gentoo tends to be less about the polished desktop experience, so I suspect we'll always lag something like Ubuntu in that regard - at least when it comes to ripping apart everything and trying something new.
Is there a need an fsck? For example, ZFS doesn't have one and I haven't heard of anybody working on it (or of anybody actually wanting one).
Um, yeah, read zfs-discuss. There are helpful folks on there who help people recover their ZFS volumes, but having a tool to do it would be much better.
fsck for ZFS or btrfs means something different than it does for ext* but it's still needed. I just had a client's new 18TB ZFS zvol go TU when the power failed and the UPS->host communication wasn't properly connected. Fortunately it wasn't very important and the important zvol wasn't active when the power failed.
btrfs will be better than ZFS for many use cases once the fsck is stable. For others ZFS will remain better, but you better have battery-backed disk cache or a monitored UPS (neither of which are appropriate requirements for large swaths of the Fedora user base).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
...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.
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.
Turn your files into butter is right. Though I don't use Fedora, I was interested to look into btrfs again when I read this post on slashdot.
Much to my surprise, directly from the main btrfs wiki: "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."
Why would RedHat choose such a file system that does not have basic support for recovery of a file system after a system crashes? This has been an essential part of file systems since the as far back as I can remember.