Maybe btrfs is more easy to recover if no compression is used, I don't use it without. Did you ever enable lzo compression?
Announcement
Collapse
No announcement yet.
CoreOS Moves From Btrfs To EXT4 + OverlayFS
Collapse
X
-
Originally posted by Micket View PostActually, you don't seem to know what happens with BTRFS. "Deleting stuff" doesn't free up space.
Comment
-
"Why not give XFS a try?"
I used it for quite a lot in my webserver because of per-directory quotas. After some time it started having such low performance that I had to switch to ext4 and get rid of quotas. No more thanks.## VGA ##
AMD: X1950XTX, HD3870, HD5870
Intel: GMA45, HD3000 (Core i5 2500K)
Comment
-
using it as well on several machines for about 2 years here. did run into an issue a few times: when the fs is improperly umounted (power failure, killing a vm, pulling out a usb drive, etc. stuff ppl shouldnt do but do all the time regardless) in some rare cases btrfs would corrupt files. ive a feeling its the one bug most other ppl hit.
Its fixed in recent versions though.
Id also note that while ext4 received a lot of testing and real world use, overlayfs didnt get all that much. openzfs either.
Comment
-
Originally posted by balouba View Postusing it as well on several machines for about 2 years here. did run into an issue a few times: when the fs is improperly umounted (power failure, killing a vm, pulling out a usb drive, etc. stuff ppl shouldnt do but do all the time regardless) in some rare cases btrfs would corrupt files. ive a feeling its the one bug most other ppl hit.
Its fixed in recent versions though.
Id also note that while ext4 received a lot of testing and real world use, overlayfs didnt get all that much. openzfs either.
Facebook could probably manage to run minix with their development team, so the argument of it being good enough for facebook isn't quite a valid one IMO. They have a huge development team and a HUGE systems administration team. Much larger than most teams, and much more oriented towards low-level hacking than a lot of other teams are going to be. That said, I suspect that they don't use it for things like database storage where integrity is a bit more crucial (edit: just googled it, they are trialing it, not necessarily running it in main production).
Comment
-
Is there any science on the root of the problems? All the popular COW filesystems seem to have problems when very low on disk space. There is also the autodefrag mount option which is supposed to fix the meta data rebalance and slowdown issues. Is there a more detailed dump of information? Were these problems happening on "normal" systems or were they tightly constrained on disk space or what?
Comment
-
Originally posted by Micket View PostJust the fact that I could fill up my drive and not being able to restore the space without adding another device to the pool is a pretty crucial flaw. The distro was a OpenSUSE factory snapshot, so, definitely a rolling distro from the start.
Happened on two machines, at around the same time. I probably have to look over them again and rebalance them before they get both get f'ed up again.
I haven't had time to figure out how to make it stop taking snapshots all the fucking time, so I just delete them for now.
See here
After reading this link: http://www.phoronix.com/vr.php?view=20949 I’m wondering why openSuse is switching from ext4 to Btrfs. Performance looks worse than ext4. Ext4 is in use on lots of computers, so most bugs have been fixed. Why is openSuse setting the default fs to Btrfs and risk the data of their users by new bugs? At least they should warn their users… For sure I’ll stick with ext4 for the nearby future and let other people risk their data and file the bugreports. Best Regards.Last edited by Slartifartblast; 20 January 2015, 05:43 AM.
Comment
-
Originally posted by jimbohale View Postoverlayfs is a lot less complicated than something like btrfs. I suspect that they encountered a few show stopping bugs in btrfs like kernel panics, I've encountered a few of those myself or data corruption bugs but those were when it was marked as experimental so I don't hold it against it. ext4 is a tried and true filesystem, so is xfs (much more so than ext4 actually but lacking drive shrinking). I suspect they want to give it a few more years, which I agree with considering CoreOS's target audience of enterprise.
Facebook could probably manage to run minix with their development team, so the argument of it being good enough for facebook isn't quite a valid one IMO. They have a huge development team and a HUGE systems administration team. Much larger than most teams, and much more oriented towards low-level hacking than a lot of other teams are going to be. That said, I suspect that they don't use it for things like database storage where integrity is a bit more crucial (edit: just googled it, they are trialing it, not necessarily running it in main production).
Comment
-
Originally posted by Micket View PostMy OpenSUSE install picked btrfs by default so I thought I'd go with it.
A few weeks later I'm stuck trying to remove data from the drive since it filled up in no-time with tons and tons of fucking snapshots.
Had to get a hold of a usb stick and format that to btrfs and add it so that I could REMOVE DATA (since removing files doesn't actually free up space, you need to rebalance the metadata manually )
Why would a rolling distro use this by default, when users have to manually watch out for their drive filling up and manually run rebalancing and deletion of snapshots every now and then? All through a few dozen terminal commands.
If you are administrating larger systems I'm sure btrfs could be really useful, but as the default for a desktop? No fucking way.
Btrfs snapshots are great for rolling release distros, because they can provide an easy way to undo changes in case an update breaks everything. (Which does happen every so often, depending on how bleeding edge your distro is.) I use that exact setup, and it works brilliantly for me.
However, it has some important caveats that are basically the result of the snapshot applying to the entire subvolume:- /home needs to be a separate subvolume, or it'll be included in the snapshots.
- The snapshots need to be automatically deleted after a few months
- If there are any databases, etc. stored on the rootfs, they also need to be separate subvolumes.
I do agree that needing to add storage in order to be able to delete files is really counter-intuitive though. The btrfs developers should probably set the defaults to create some reserved space on btrfs volumes specifically for improving this corner case.
Originally posted by chrisb View PostWhat do you expect it to do? When your drive is full, the only options are to add more space or delete stuff. Obviously it can't just automatically delete your data... So if you fill the drive, you will need to either add more space or manually delete stuff.
Btrfs has some great features, but it's easy to shoot yourself in the foot with it. I think it's a bad idea for distros to implement things like automatic snapshots, because they have implications that the user really needs to know about - just google 'btrfs enospc' to see how many people have had similar to experiences to Micket.
Originally posted by Nelson View PostIs there any science on the root of the problems? All the popular COW filesystems seem to have problems when very low on disk space. There is also the autodefrag mount option which is supposed to fix the meta data rebalance and slowdown issues. Is there a more detailed dump of information? Were these problems happening on "normal" systems or were they tightly constrained on disk space or what?- automatic snapshots can fill up your disk quite easily
- snapshots make freeing up space occupied by large, old files difficult
- plenty people use an SSD with btrfs for /, which means there isn't that much space in the first place
- figuring out how much free space you actually have is quite difficult under btrfs. For example, there's no way to determine how much space is used by a subvolume or a snapshot - you can only access stats on a per-volume level.
The general consensus seems to be that btrfs is fine, as long as you never let the disk usage grow beyond 90%. (Adding reserved space would essentially formalize that, though people would likely complain about the loss of space.) But I can definitely see why someone who could use ext4+overlayfs instead would avoid it - the complexity and problems associated with these features aren't negligible. I use btrfs all of my systems, but I would never suggest its use in an enterprise setting where you want to be able to forget it's even there.
Comment
Comment