Fedora 16 To Use Btrfs Filesystem By Default 198
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."
Cool. (Score:3, Funny)
Can't wait to turn all my files into butter.
Re:Cool. (Score:5, Insightful)
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.
Re: (Score:2)
Because it's Fedora, which is explicitly a testbed distro for newer technologies, and the problem is limited to disks that don't handle flush requests correctly. If you care about a 100% reliable system, you shouldn't be using Fedora in the first place. If you're willing to accept a very small risk of losing everything and having to restore from backup, you get to play with the shiny new toys.
Re: (Score:3, Insightful)
Re:Cool. (Score:4, Insightful)
You get the reliability you select. All you need to do to avoid this issue with brtfs is 1) use ext4 instead, or 2) use a hard disk that doesn't lie about whether or not it's buffering.
Fedora is not production ready even in the sense of a daily use desktop with data that can't be recovered from backup, even without this problem. It's explicitly a testbed distro, and always has been.
Re: (Score:2)
They've had a btrfsck for a long time, it's just not actually capable of detecting or fixing most forms of filesystem corruption yet. (I believe the original version literally did nothing.)
Rollback system changes (Score:2)
Re: (Score:3)
Sure, you can sort of do that with LVM now.
What doesn't work with LVM, unfortunately, is using snapshots that allow you to "roll forward" if the system updates work out all right and you want to accept the updates into your main volume :-/
Re: (Score:2)
The LVM merge feature has been available for around a year now, at least it's available in F14. Or are there some issues with it that make it unsuitable for doing that?
Re: (Score:2)
Hmm, I don't know, I just remember reading about merging being problematic when I was trying to do that some time ago. Of course I'm just using CentOS for work most of the time, so it'll be even longer before I see it.
http://www.jonnor.com/2010/02/lvm-snapshot-merging-avaliable/ [jonnor.com]
Re: (Score:2)
Sure, you can sort of do that with LVM now.
What doesn't work with LVM, unfortunately, is using snapshots that allow you to "roll forward" if the system updates work out all right and you want to accept the updates into your main volume :-/
I bet you couldn't find five sysadmins in the (one one) country who do this in production.
Brtf alone isn't going to bring to Linux:
create new boot environment 'foo' /mnt /mnt
mount 'foo' to
install patches/updates/new software to root at
umount 'foo'
activate 'foo'
reboot
Then from the boot menu, pick 'previous_foo' if 'foo' is broken.
That's a lot of really different projects that would have to come together for Linux to pull it off, one being dramatically different distro to distro. We've already heard folks sh
Re: (Score:3)
I believe in btrfs that a snapshot is itself a mountable structure, so in theory all you have to do is do a snapshot called "previous_foo" and then install your changes, and if it doesn't work boot with (real_)root= on your kernel line.
Not a whole lot needs to actually come together unless you want it all automated. Then again, I run gentoo so my grub.conf is hand-configured anyway. :)
Re: (Score:3)
We've already heard folks shout "layering violation" at basic parts of ZFS itself
And the person who said this clarified it saying that it wasn't a criticism. It's also wrong. ZFS has very clean layering, it just doesn't put the layers in the same place as System V.
Re: (Score:2)
In apt systems at least... /
Create an overlay filesystem based on
chroot into the overlay
run updates
have a handy dandy "boot into overlay" option (I've done this, knoppix does this, it isn't hard and they CAN put it in there with no hassle)
test
test more
give it the okay!
reboot into a "collapse the changes into the mainline root" mode which will then reboot normally (into the freshly collapsed root). One can collapse the two using rsync. It will be very fast
Profit.
Take you two hours to do or about three weeks
Re:Rollback system changes (Score:4, Insightful)
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 [fedoraproject.org]
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.
Re:Rollback system changes (Score:5, Informative)
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)
Re:Rollback system changes (Score:4, Interesting)
Re: (Score:2, Insightful)
Snapshot takes minimal disk space compared to a backup
Use an incremental backup?
I'm not saying it wouldn't be a nice feature to have built into the OS, just that instead of hoping for such a feature in future, people can have similar functionality right now if they really want it.
Re:Rollback system changes (Score:5, Interesting)
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.
Re: (Score:2)
It's definitely convenient if you want to be able to do this kind of thing very often, and for something that you just did say 10 minutes ago. But for example the Volume Shadow Copy functionality we have on our Windows file server just runs incremental snapshots every night, which doesn't get in anyone's way, and avoids the performance hit of writing everything twice every time you save (which admittedly won't be a big deal in most cases).
Re: (Score:2)
and avoids the performance hit of writing everything twice every time you save (which admittedly won't be a big deal in most cases).
I think you misunderstand copy-on-write. Copy-on-write doesn't write stuff twice, the point of it is that it writes almost nothing at all. If I have a file Foobar1 and copy it to Foobar2 both of them will point to the same data on the drive. The file will not be copied, but instead the filesystem will simply recorded that Foobar2 is a copy of Foobar1. However when I change blocks in Foobar2, the changes will be written to new blocks and not change blocks of Foobar1.
It is essentially the same what Volume Sha
Re: (Score:2)
Okay. That's pretty damn cool :)
Re: (Score:2)
Re-installing windows is hardly what I would call a viable roll back...
- Dan.
Re: (Score:2)
Never worked for me...
still not using grub2? (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:3, Informative)
Yes, and? I thought it was well known that fedora is the test bed for RHEL.
Re: (Score:3)
Yes, and therefore "When it comes to adopting the newest technologies, Fedora is always at the front among the major Linux distributions" is a dirty lie. It should be "When it comes to convincing fools to beta-test RHEL for us, Fedora is the shiznit!" What does "major Linux distributions" mean, anyway? I'd give that to Gentoo, which often makes functionality available very early.
Fedora is of course at the forefront of adopting the newest technologies developed by Red Hat. Some of what they have written has
Re:still not using grub2? (Score:5, Informative)
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.
Re: (Score:2)
When I was running Gentoo it was trivially easy to jump on the bleeding edge. Is that no longer true? That was my second-favorite thing about it (number one being that I actually ended up with a build for the K6 I was using it on.)
Re: (Score:3)
It is, but keep in mind that there are many bleeding edges.
You could be running bleeding edge postfix, or you could be running bleeding edge sendmail - the distro doesn't care which.
You could be running bleeding edge KDE or Gnome - again we don't care.
You could be running the default openrc, or perhaps one day you could be running systemd (right now we care - some would like to change that).
There is a default experience if you follow the guidebook and don't mess with certain flags/packages/etc. It can be s
Re: (Score:2)
people get grumpy when they have to learn something new but grub2 is definitely a step forward. As an Ubuntu user I don't even have to care. As a nerd I have tinkered with it and I don't get why people are whinging.
u r a stupid trollbag (Score:2)
Your presence requested 2 answer simple question (Score:-1)
by Anonymous Coward on 06-09-11 15:01 (#36394150)
http://tech.slashdot.org/comments.pl?sid=2225174&cid=36390518 [slashdot.org]
This is why people like me think you're a fuckhead, apk. You log in as AC so you can sign some posts and not others. Go piss up a very short rope.
mdadm woes begone? (Score:3)
I was handed a block of drives that had been in a server recently with software raid and asked to rebuild the array and recover the data. This had been assembled with mdadm. Will this change make such recovery a non issue with snapshots and the like, providing of course the array had been running btrfs?
- Dan.
Re:mdadm woes begone? (Score:5, Informative)
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.
Re:mdadm woes begone? (Score:4, Interesting)
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...
Re: (Score:2)
Sources for this? (Score:5, Informative)
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 [fedoraproject.org] or http://thread.gmane.org/gmane.linux.redhat.fedora.devel/149196/focus%3D149215 [gmane.org] to lend a little authority might have been nice...
Re:Sources for this? (Score:4, Insightful)
But how does that drive ad clicks for digitizor if one links to the official source? Silly you.
Re: (Score:2)
I wonder if they have a working fsck yet? (Score:4, Insightful)
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.
Re:I wonder if they have a working fsck yet? (Score:4, Informative)
Hopefully they know something about it being released soon since making the decision to use it.
Re: (Score:2)
It seems like they have: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=blob;f=btrfsck.c;h=63e44d1dbc26f2ee9f6ef29c08ae0eb9d19e48db;hb=HEAD [kernel.org]
Re: (Score:2)
Regarding fsck, from: https://fedoraproject.org/wiki/Talk:Features/F16BtrfsDefaultFs#Recovery_strategy [fedoraproject.org]
fsck must work. It should be tested for a longer period to see if it's really working.
Would be nice if this speeds up the work on btrfs.fsck.
Re: (Score:2)
No plans for an fsr either.
So far, you need to stay at ext2/3 or xfs if you want defragmentation.
Re: (Score:2)
The "defragment" in btrfs isn't a defragmenter in the normal sense of the word (aside from being broken) -- you can only defragment individual files, not file systems.
It's also incompatible with copy-on-write, as it forces a copy to be made.
Unless the entire design changes, you might as well just use the workarounds you've used on ext4/reiser for a long time.
Re: (Score:3)
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).
Re:I wonder if they have a working fsck yet? (Score:5, Informative)
It says right here on the btrfs wiki [kernel.org]: "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.
Re:I wonder if they have a working fsck yet? (Score:4, Informative)
I have seen this issue with other filesystems. It comes from when the hard drives *lie* to the RAID or I/O controller stating that they don't buffer or are not buffering when in reality, they are. It's really frustrating since you can't trust the drives have written out the data.
Re: (Score:3, Insightful)
This. I run btrfs on my home file server and lost a half year of data due to a power outage corrupting the filesystem. Afterwards I was looking around for its fsck utility only to find it does not yet exist. Btrfs may be the way of the future, but as is, it's still too soon.
Re: (Score:2)
Translation:
"We can get fucked over when a device lies to us about buffering just like any other filesystem, and it's not our fault if you have shitty hardware that doesn't follow instructions like it's supposed to."
Re:I wonder if they have a working fsck yet? (Score:5, Interesting)
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).
Re: (Score:2)
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).
Actually, a large swath of the Fedora user base runs laptops, which depending on how you look at it could be considered either a battery-backed disk cache or a monitored UPS.
Re: (Score:2)
Actually, a large swath of the Fedora user base runs laptops, which depending on how you look at it could be considered either a battery-backed disk cache or a monitored UPS.
Ideally. I've had my Fedora run out of battery while shutting down (triggered by power management) often enough that I wouldn't trust it. I run my ext4 with data=journal.
Re: (Score:3)
Yes it does (Score:2)
No matter how well you design your FS, errors can happen. Generally it is because of hardware below it but the cause isn't important, the recovery is. That's why NTFS has chkdsk. Many people don't know it and assume it isn't needed because it runs extremely rarely, a user will likely never see it. It isn't like the old FAT32 days where you needed to run it on every crash. However it is still there, and we (IT) still use it from time to time. If something goes wrong, the filesystem can be left in a state whe
Comment removed (Score:4, Interesting)
Re:My experiences with btrfs (Score:4, Informative)
. 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.
With RAID 1 (simple mirroring), your volume is limited to the smallest of the components. A 40 GB and a 2 TB drive put together yields a 40 GB RAID 1 volume.
Re: (Score:2)
Re:My experiences with btrfs (Score:4, Informative)
With RAID 0 you get twice the amount of the smallest unit.
Using a 40 GB and an 2 TB HD will give you an 80 GB RAID 0.
Re: (Score:3)
Does btrfs actually stripe like this, or does it simply keep a copy on two volumes for RAID1, and spread data around for RAID0?
You can tell btrfs to even keep two copies on the same volume if you want, I think.
They call it RAID, but I don't think it is really the same thing. The RAID5-like features and reshaping don't exist yet (the last time I checked). Then again, maybe it supports both modes of operations - if there is one thing about btrs is that it has a million optional features.
Re: (Score:2)
I read one person's blog a few weeks back about how he had BTRFS set on attempting to fix something, but not sure what. It was reading the HD at full speed for over a day. It was effectively stuck in a loop. It was eating up all of his IO and also a large portion of his CPU, and a modern 8 core server with several gigs of ram. Also, because the FS was stuck trying to fix the data, the computer refused to shutdown as the FS would not release.
He had to do a forceful shutdown and that messed up his FS even mor
What about fsck support? (Score:2)
Re: (Score:3)
I've ran BtrFS's arch rival, ZFS for years, and I have never ever had to fsck the disk, even after power outages and crashes (yes Solaris crashes rather spectacularly sometimes). In theory a good file system should always be in a consistent state and never require fscking. Of course you could mean trying to fsck a disk when a hard drive starts failing, but I still don't see how that is useful; fscking a failed drive might just stir the data more. I'll settle for being able to pull off as much data as I c
Re: (Score:2)
If there is no fsck for btrfs then what is this?
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=blob;f=btrfsck.c;h=63e44d1dbc26f2ee9f6ef29c08ae0eb9d19e48db;hb=HEAD [kernel.org]
Re: (Score:2)
It's fairly new so most people probably don't know about it. It has been available in Rawhide for a couple of months or so now.
Re: (Score:2)
Never mind (Score:2, Funny)
ReiserFS will kill it
Availability Notice (Score:4, Insightful)
...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.
Re: (Score:2)
You do know what Fedora is supposed to be, right ?
Re: (Score:2)
Is anyone else thinking of when Ubuntu implement ext4 support? Turned out there was a major bug that caused kernel lockups when emptying the trash.
I can only imagine something similar will happen here...
Hierarchical File System? (Score:3, Interesting)
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.
This is why I left Red Hat Behind (Score:2)
Re: (Score:3)
The fragmentation already exists. Need a stable, supported release? Use RHEL. Need to use it without the Red Hat strings attached but still have the stability? Use CentOS. Want the hobbyist bleeding edge? Use Fedora.
Re: (Score:2)
Why I left Red Hat..... (Score:2)
I don't really need to say much more. Fedora is just too bleeding edge even for non-production IMHO. I don't want to boot up my box and have my file system screwed. Sorry Red Hat. You should go back to the old model of eating your own dog food. Perhaps a model like Ubuntu with a Red Hat LTS and a Red Hat Latest Version, but the latter being a little more stable than Fedora. I digress, this is why I am on Ubuntu now. It's not perfect, but it has been a much more positive experience for me than running Fedora
Re: (Score:3, Informative)
Re:Btrfs features forced on users? (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
It isn't a problem only for dual boot. It's a problem if you install Fedora as the only OS on a blank drive too.
If you use the CD they recommend to "get Fedora" (or even another one from "Additional options") you get no choice in file systems.
Only if you know about the difference, and hunt down the Install CD (or DVD) under "All download methods" can you get a choice of filesystems.
Re: (Score:2)
/currently running FreeBSD for the sake of ZFS, because it's the only way to not lose data when hard disks die.
Re: (Score:2)
ReiserFS 3 doesn't support many of the functions modern file systems need, and Reiser4 was never finished before you-know-what.
JFS is a good solid file system; and probably what I would use if I didn't use xfs. When I tried it, it performed admirably -- it only lacks a dump/restore program that handles all the file system metadata like xfsdump/xfsrestore does for xfs.
Re: (Score:2)
If I recall correctly (haven't installed Fedora from scratch since about version 11), you can pick your filesystem using the advanced options in the installer, just like the Ubuntu installer. I don't recall whether this option is left out of the LiveCD installer, but I doubt it. As far as I understand, the LiveCD just has less packages installed by default...but the installer it runs is otherwise the same.
Re: (Score:2)
I would have thought the same thing but I just checked the F15 LiveCD in VMWare using the default partition layout and although you can change the filesystem for the /home mount point it complains about the /boot and / mount points. It states /boot must be on ext4 and that / must be the same as the LiveCD (which does happen to be ext4).
So I would assume unless they make some changes to the installer for F16 or the LiveCD is offered in an ext4 and btrfs flavours then anyone wanting to override the default c
Re: (Score:2)
Re: (Score:2)
On top of that, I am quite certain that this isn't going to affect upgrades at all.
The partition layout/filesystem types that you had before are going to be the ones you have after just like the vast majority of upgrades before now.
So no one's existing files are going to be affected.
Re:But... btrfs isn't stable (Score:5, Insightful)
It makes perfect sense. Btrfs won't get stable for RHEL unless it's beta tested in Fedora first.
Re: (Score:2)
Nobody said Fedora was stable.
Re: (Score:2)
Re: (Score:2)
Reiser strikes again?
Re: (Score:2)
Damnit! I wasn't sure, so I just went for it. Best policy :p
Re: (Score:3)
Yes, it was officially fixed in 2.6.32 or something like that. They keep adding more features and improving it, but the format is supposed to be fixed by now.
Anyway. I don't know if default is a good idea, but even Debian offered btrfs as an option when I installed it on my new laptop last month. It is hardly cutting edge anymore ;)
Re:Fedora is essentially RHEL beta (Score:5, Informative)
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.
Re: (Score:3)
"64 bit CRC"? No. ZFS uses 256 bit checksums [oracle.com] for each block.
Also, ZFS does not implement RAID-5, RAID-6 or any of the conventional RAID modes; but it has "RAID-like" modes (e.g. mirrored vdev, RAID-Z [oracle.com], RAID-Z2).
Re:Fedora is essentially RHEL beta (Score:4, Interesting)
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.
Re: (Score:2)
RHEL 6, ext4 only, enabled by mount option:
linky [redhat.com]
Re: (Score:2)
ZFS isn't "just" a filesystem (Score:2)
Re: (Score:2)
Re: (Score:2)