Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora 16 To Use Btrfs Filesystem By Default

timothy posted more than 3 years ago | from the taking-a-bold-line dept.

Data Storage 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."

Sorry! There are no comments related to the filter you selected.

Cool. (3, Funny)

Anonymous Coward | more than 3 years ago | (#36387576)

Can't wait to turn all my files into butter.

Gummi Bears! (0)

Anonymous Coward | more than 3 years ago | (#36387938)

Dashing and daring,
Courageous and caring,
Faithful and friendly,
With stories to share.
All through the forest,
They sing out in chorus,
Marching along,
As their song fills the air.

Gummi Bears!!
Bouncing here and there and everywhere.
High adventure that's beyond compare.
They are the Gummi Bears.

Magic and mystery,
Are part of their history,
Along with the secret,
Of gummiberry juice.
Their legend is growing,
They take pride in knowing,
They'll fight for what's right,
In whatever they do.

Gummi Bears!!
Bouncing here and there and everywhere.
High adventure that's beyond compare.
They are the Gummi Bears.
They are the Gummi Bears!!

Re:Cool. (0)

Anonymous Coward | more than 3 years ago | (#36389446)

Don't worry, you can run fsck.btrfs to fi... oh.. wait... that command doesn't actually repair anything yet.

Re:Cool. (0)

Anonymous Coward | more than 3 years ago | (#36390072)

GLADoS says:

The secret to truly cynical cake is extra salt in the password hash

Dual boot? (0)

Anonymous Coward | more than 3 years ago | (#36387598)

So how will this affect the dual boot folks who use a partition for multiple OS'es?

Re:Dual boot? (0)

Anonymous Coward | more than 3 years ago | (#36387642)

Just because a filesystem defaults to one thing doesn't mean that it won't accept another FS type.

Re:Dual boot? (0)

Anonymous Coward | more than 3 years ago | (#36387892)

So how will this affect the dual boot folks who use a partition for multiple OS'es?

If they use an OS that can't read btrfs they won't be able to read btrfs..

Btrfs features forced on users? (1)

Denogh (2024280) | more than 3 years ago | (#36387600)

Pretty sure default filesystem != mandatory. They're not going to suddenly drop support for ext*.

Re:Btrfs features forced on users? (3, Informative)

Denogh (2024280) | more than 3 years ago | (#36387620)

Oh wait... I'm a dummy that can't read.

Re:Btrfs features forced on users? (5, Informative)

arth1 (260657) | more than 3 years ago | (#36387976)

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:Btrfs features forced on users? (1)

Denogh (2024280) | more than 3 years ago | (#36388290)

You are correct in all of that.

I've been installing my Fedora KDE spin from live disks since early in 13. I expect this is going to be an inconvenience for future installs, but hardly insurmountable. Finding the install image instead of the live image will be the worst part.

Of course, this won't be a problem for current installs, as I'm certain `preupgrade` won't be reformatting anything.

Re:Btrfs features forced on users? (1)

drunkahol (143049) | more than 3 years ago | (#36388538)

Conversion to btrfs, however, isn't out of the question. It is unlikely that this would be forced on you during pre-upgrade though.

Re:Btrfs features forced on users? (0)

Anonymous Coward | more than 3 years ago | (#36389034)

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.

Really not trying to come off as an arse, but is Fedora really that shoddy? The Ubuntu live cd installer defaults to EXT4, but a whole slew of other filesystems are about three clicks away and the choices range from archaic to esoteric to bleeding edge.

Re:Btrfs features forced on users? (1)

MikeUW (999162) | more than 3 years ago | (#36389664)

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:Btrfs features forced on users? (1)

S.O.B. (136083) | more than 3 years ago | (#36390364)

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 choice of btrfs will have to use an alternate install method.

Re:Btrfs features forced on users? (0)

Anonymous Coward | more than 3 years ago | (#36388042)

Fedora is a bleeding edge distribution. Noone said you can't use ext*, just that btrfs is going to be the *default*. If you don't like it, change it, or simply don't use a bleeding edge distribution.

Re:Btrfs features forced on users? (1)

Bob Loblaw (545027) | more than 3 years ago | (#36389240)

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.

But... btrfs isn't stable (0)

Anonymous Coward | more than 3 years ago | (#36387606)

This doesn't make sense.

Re:But... btrfs isn't stable (4, Insightful)

MrHanky (141717) | more than 3 years ago | (#36387790)

It makes perfect sense. Btrfs won't get stable for RHEL unless it's beta tested in Fedora first.

Re:But... btrfs isn't stable (0)

mcavic (2007672) | more than 3 years ago | (#36388012)

Fedora isn't stable. It might work perfectly well, but the updates are too fast and many to be considered stable.

Re:But... btrfs isn't stable (1)

Nimey (114278) | more than 3 years ago | (#36388514)

Nobody said Fedora was stable.

Re:But... btrfs isn't stable (1)

TheRaven64 (641858) | more than 3 years ago | (#36389768)

That's the point. Red Hat enables it in Fedora and, when they stop getting bug reports, they enable it in RHEL.

Is the disk format fixed? (0)

Anonymous Coward | more than 3 years ago | (#36387616)

So.. Is the format of btrfs fixed now? Because last time I looked at the kernel it had a great big warning about possible future changes.

Re:Is the disk format fixed? (2)

Carewolf (581105) | more than 3 years ago | (#36387948)

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

Fedora is essentially RHEL beta (1)

Anonymous Coward | more than 3 years ago | (#36387638)

This means that all the good things with BTRFS could be stable enough for servers within a year or so. Hopefully, this means that Linux admins won't have to spend much more time longingly lusting after ZFS.

Re:Fedora is essentially RHEL beta (1)

mcavic (2007672) | more than 3 years ago | (#36388040)

Well, give them 2 years. As far as I know, RHEL still doesn't have TRIM support.

Re:Fedora is essentially RHEL beta (1)

idontgno (624372) | more than 3 years ago | (#36388534)

RHEL 6, ext4 only, enabled by mount option:

mount -t ext4 -o discard <device> <mountpoint>

linky [redhat.com]

Rollback system changes (2)

EponymousCustard (1442693) | more than 3 years ago | (#36387646)

Does this mean we are a step closer to the possibility of snapshotting system states and rolling back to before a bunch of updates were installed?

Re:Rollback system changes (0)

Anonymous Coward | more than 3 years ago | (#36387746)

Sure. The solution is to install Windows.

Re:Rollback system changes (0)

Anonymous Coward | more than 3 years ago | (#36387872)

I don't think he was asking how to degrade his system.

Re:Rollback system changes (0)

Anonymous Coward | more than 3 years ago | (#36388016)

I don't think he was asking how to degrade his system.

No, he was asking how he could roll back to a known state before the latest patches were installed. The solution that the other Anonymous Coward proposed - to install Windows - is certainly valid as it has been able to do this for many years.

Re:Rollback system changes (1)

Hylandr (813770) | more than 3 years ago | (#36388628)

Re-installing windows is hardly what I would call a viable roll back...

- Dan.

Re:Rollback system changes (1)

Ossifer (703813) | more than 3 years ago | (#36390194)

Never worked for me...

Re:Rollback system changes (0)

Anonymous Coward | more than 3 years ago | (#36388366)

...or defile his system.

Re:Rollback system changes (0)

Anonymous Coward | more than 3 years ago | (#36388238)

Sure. The solution is to install Windows.

Lol. He didn't want to roll back from broken to even more broken.

Re:Rollback system changes (0)

somersault (912633) | more than 3 years ago | (#36387798)

Don't see why the file system would really make a difference for that.

You could also have a look at these new fangled "backup" thingies. Keep your user data in a separate partition for example, and you can backup/restore the system separately. You'd probably also want to backup/restore in that situation too ~/.* of course.

Re:Rollback system changes (1)

Anonymous Coward | more than 3 years ago | (#36387974)

If the file system supported snapshots and copy-on-write it would really make a difference.

Re:Rollback system changes (4, Informative)

BrentH (1154987) | more than 3 years ago | (#36387994)

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 (4, Interesting)

EponymousCustard (1442693) | more than 3 years ago | (#36388000)

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.

Re:Rollback system changes (1, Insightful)

somersault (912633) | more than 3 years ago | (#36388154)

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 (4, Interesting)

grumbel (592662) | more than 3 years ago | (#36389194)

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:Rollback system changes (1)

somersault (912633) | more than 3 years ago | (#36389508)

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:Rollback system changes (2)

rwa2 (4391) | more than 3 years ago | (#36387894)

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:Rollback system changes (1)

Znork (31774) | more than 3 years ago | (#36387982)

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:Rollback system changes (1)

ToasterMonkey (467067) | more than 3 years ago | (#36388244)

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'
mount 'foo' to /mnt
install patches/updates/new software to root at /mnt
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 shout "layering violation" at basic parts of ZFS itself, what hope does all this have?

Re:Rollback system changes (2)

Rich0 (548339) | more than 3 years ago | (#36388556)

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:Rollback system changes (2)

TheRaven64 (641858) | more than 3 years ago | (#36389918)

Nexenta does this already. They have an apt-clone utility that wraps apt-get and ZFS snapshots. It takes a snapshot, then does the upgrade. If you don't like it (e.g. stuff breaks), you roll back to the snapshot. If you do, then you just delete the snapshot and continue.

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:Rollback system changes (1)

doublebackslash (702979) | more than 3 years ago | (#36390160)

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 if you wanted it to be useful for the unwashed masses. Nobody does this because.... ummm... Actually I'm not sure, but I'll bet it has a lot to do with POTENTIALLY breaking things and you can't put that into a distro.

However, feel free to whip it up and enjoy. I just take a nice sturdy backup before a major change. If you think that restoring a backup is too long / costly / unreliable then you have a problem with you backup system. Also: test environments are handy. I guess those are good arguments against having a built-in "try and see" mode. Breaks things and there are better solutions than mucking about with your boot config and filesystems for most.

I guess I don't have a point... Enjoy either way!

Re:Rollback system changes (3, Insightful)

Bob Loblaw (545027) | more than 3 years ago | (#36388940)

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.

still not using grub2? (3, Interesting)

drinkypoo (153816) | more than 3 years ago | (#36387648)

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:still not using grub2? (2)

BreezeC (2040184) | more than 3 years ago | (#36387692)

Maybe the boss redhat don't like grub2.

Re:still not using grub2? (2, Informative)

grasshoppa (657393) | more than 3 years ago | (#36387774)

Yes, and? I thought it was well known that fedora is the test bed for RHEL.

Re:still not using grub2? (2)

drinkypoo (153816) | more than 3 years ago | (#36387890)

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 been very nice. I don't want to take anything away from them. I only find this blog entry to be an inane piece of marketfluff.

Re:still not using grub2? (4, Informative)

Rich0 (548339) | more than 3 years ago | (#36388672)

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:still not using grub2? (1)

drinkypoo (153816) | more than 3 years ago | (#36389864)

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

mdadm woes begone? (2)

Hylandr (813770) | more than 3 years ago | (#36387650)

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? (4, Informative)

guruevi (827432) | more than 3 years ago | (#36388148)

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? (3, Interesting)

Rich0 (548339) | more than 3 years ago | (#36388846)

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

Sources for this? (5, Informative)

Dan Dankleton (1898312) | more than 3 years ago | (#36387656)

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? (3, Insightful)

Lunix Nutcase (1092239) | more than 3 years ago | (#36387728)

But how does that drive ad clicks for digitizor if one links to the official source? Silly you.

Re:Sources for this? (1)

_Sprocket_ (42527) | more than 3 years ago | (#36388024)

Your links are nice background / support. But they're hardly read as well. Sure - one can hash out the details via the wiki link. But I could see those details being missed without the narrative. So in this case, I would say the blog entry added something to the story unlike some blog entries we see that are simply re-hashing other blogs without adding anything themselves. If I had written the submission, I would have picked the blog entry as the primary link with your wiki link as supporting. If I had to pick one, I'd go with the blog entry. YMMV.

in other news ... (1)

Anonymous Coward | more than 3 years ago | (#36387658)

the Guinness World of Records has awarded the Shortest Living Filesystem Record to ext4

Re:in other news ... (1)

somersault (912633) | more than 3 years ago | (#36387838)

Reiser strikes again?

Re:in other news ... (0)

Anonymous Coward | more than 3 years ago | (#36387912)

too soon.

Re:in other news ... (1)

somersault (912633) | more than 3 years ago | (#36387988)

Damnit! I wasn't sure, so I just went for it. Best policy :p

Re:in other news ... (1)

Jello B. (950817) | more than 3 years ago | (#36388090)

if a joke is funny it's never too soon.

I wonder if they have a working fsck yet? (3, Insightful)

Thrakkerzog (7580) | more than 3 years ago | (#36387704)

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? (1)

cronius (813431) | more than 3 years ago | (#36387866)

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:I wonder if they have a working fsck yet? (1)

arth1 (260657) | more than 3 years ago | (#36388014)

No plans for an fsr either.
So far, you need to stay at ext2/3 or xfs if you want defragmentation.

Re:I wonder if they have a working fsck yet? (0)

Anonymous Coward | more than 3 years ago | (#36389410)

So far, you need to stay at ext2/3 or xfs if you want defragmentation.

False. You obviously argue from ignorance, so I'd suggest you read up on how btrfs actually works. Look here [kernel.org] for an example. Google will tell you even more.

Re:I wonder if they have a working fsck yet? (1)

arth1 (260657) | more than 3 years ago | (#36390204)

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:I wonder if they have a working fsck yet? (2)

Just Some Guy (3352) | more than 3 years ago | (#36388424)

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? (5, Informative)

cratermoon (765155) | more than 3 years ago | (#36388490)

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? (3, Informative)

Mullen (14656) | more than 3 years ago | (#36388754)

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:I wonder if they have a working fsck yet? (0)

Anonymous Coward | more than 3 years ago | (#36389568)

Can you test whether your drives behave properly?

Re:I wonder if they have a working fsck yet? (3, Insightful)

maskedbishounen (772174) | more than 3 years ago | (#36389340)

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:I wonder if they have a working fsck yet? (1)

Anonymous Coward | more than 3 years ago | (#36388684)

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

One could argue that the scrub function of the zpool command is comparable to an fsck.

--AC

Re:I wonder if they have a working fsck yet? (5, Interesting)

bill_mcgonigle (4333) | more than 3 years ago | (#36388698)

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:I wonder if they have a working fsck yet? (2)

nairnr (314138) | more than 3 years ago | (#36389630)

Well, ZFS has scrub which goes through and verifies all checksums, for mirror or raidz it repairs and discrepancies so it is fsck like.

My experiences with btrfs (3, Interesting)

Gaygirlie (1657131) | more than 3 years ago | (#36387898)

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.

Re:My experiences with btrfs (3, Informative)

arth1 (260657) | more than 3 years ago | (#36388030)

. 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:My experiences with btrfs (1)

Gaygirlie (1657131) | more than 3 years ago | (#36388178)

My mistake, I meant raid0, ie. with striping. The odd thing is that the tools report it as raid1. And yes, I have way more stuff there than the smallest drive, so it can't be raid1.

Re:My experiences with btrfs (3, Informative)

arth1 (260657) | more than 3 years ago | (#36388356)

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:My experiences with btrfs (2)

Rich0 (548339) | more than 3 years ago | (#36388906)

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:My experiences with btrfs (1)

Bengie (1121981) | more than 3 years ago | (#36388210)

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 more. He said the HD was left in a corrupted state and no tools would fix it.Luckily this was a test machine and he had a full back-up of the data. He reformatted and put EXT on and it worked fine.

BTRFS does not sound ready.

Re:My experiences with btrfs (0)

Anonymous Coward | more than 3 years ago | (#36388246)

Well, it's not ready. There's no stable release yet. This is why you don't run Fedora on a production server.

Re:My experiences with btrfs (0)

Anonymous Coward | more than 3 years ago | (#36388510)

BTRFS does not sound ready.

It's ready to go into an Alpha test version of Fedora 16, so that it can get some serious testing. Whether it's stable enough to stay there for release is a different story.

What about fsck support? (2)

edeefelt (771994) | more than 3 years ago | (#36387908)

What about fsck support? The last time I checked, btrfs does not support this important feature to allow recovering from hard disk issues.

Re:What about fsck support? (0)

Anonymous Coward | more than 3 years ago | (#36388408)

Because it is not a journalised FS, it's a COW FS, it does not need to go offline to be repaired. It can repair itself online or allow you to mount the last working/clean version of the FS.

Re:What about fsck support? (1)

Gaygirlie (1657131) | more than 3 years ago | (#36388688)

Because it is not a journalised FS, it's a COW FS, it does not need to go offline to be repaired. It can repair itself online or allow you to mount the last working/clean version of the FS.

Well, superblocks et al can still get corrupted, and at the moment the only way of repairing issues seems to be full rebalancing of the whole filesystem. That is VERY time consuming, not to mention that it causes loads of unnecessary I/O. An fsck utility could just instead rebalance the parts that need it resulting in much less overhead and time spent.

Re:What about fsck support? (2)

caseih (160668) | more than 3 years ago | (#36388570)

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 can, fsck or no fsck.

i like my filesystems.. (1)

Anonymous Coward | more than 3 years ago | (#36388060)

..how i like my women ... FAT and 16

Never mind (1, Funny)

bigjocker (113512) | more than 3 years ago | (#36388194)

ReiserFS will kill it

Availability Notice (4, Insightful)

mgmartin (580921) | more than 3 years ago | (#36388704)

Quoted from man mkfs.btrfs on Fedora 15.

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

BTRFS and RAID5/6 (1)

spain (612172) | more than 3 years ago | (#36388780)

This is good news, I've been thinking about trying BTRFS out for a while now.

One big question, for me at least - does BTRFS have full built-in support for RAID5 and RAID6? The last time I checked it was still "under development".

Hierarchical File System? (3, Interesting)

drunkahol (143049) | more than 3 years ago | (#36388912)

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.

Re:Hierarchical File System? (1)

drunkahol (143049) | more than 3 years ago | (#36389056)

Oh - and inline de-dupe. Much discussion on it in some lists, but it's a killer feature that would be of huge benefit in the right place.

Argue all you like where that right place is, but an admin ought to have the right to use a tool such as dedupe where they like - even if that may not be your ideal use for dedupe.

Error: Sparse file not found (0)

Anonymous Coward | more than 3 years ago | (#36389458)

Error: Sparse file not found: Why oh why is BTRFS not wanting to create a nice sparse file for me on boot? Oh wait! I know! Its because BTRFS *CAN'T* make a sparse file. Its not something that BTRFS does. Or at least not yet.

Restore from suspend (1)

PixelSmack (837457) | more than 3 years ago | (#36389896)

There is currently alot of work to be done, if you have btrfs mounts at the moment in F15 then you system hangs a few seconds after restoring from a suspend.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?