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...
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.
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.
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)
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.