btrfs is still unstable
|
Author | Content |
---|---|
gus3 Aug 06, 2010 2:11 AM EDT |
It's marked as "experimental, unstable disk format" in the Linux configuration. So what if its performance has made tremendous improvements in recent developments (and I ate my words on this)? It's still foolish to use it for persistent storage of critical data. |
herzeleid Aug 06, 2010 10:48 AM EDT |
Oh, I don't know - the fact that the disk format is still subject to change doesn't make it "foolish to use" IMHO. Of course, it depends on how paranoid you want to be. I know people who think it's foolish to ever consider using a database other than oracle for storing data of any importance. It may take a few years for btrfs to earn the reputation that will make the most conservative IT folk trust it, but I've no doubt it will end up being quite stable indeed. In the meantime it's worth getting familiar with and putting through its paces. |
jezuch Aug 06, 2010 5:53 PM EDT |
AFAIK that scary note about format changes is mostly obsolete. Developers kinda sorta stabilized it quite some time ago and the only format change that had to be done was done in a normal, "stable" way with backward compatibility code and stuff. You know how usually documentation lags behind reality ;) |
azerthoth Aug 06, 2010 6:32 PM EDT |
heck I still wont use EXT4 for anything other that playing around with. The write delay to fudge write speed test results still exists. Reading another thread about using EXT4 format on a USB interface which incurs yet another write delay, ew ew ew. EXT4 is playing russian roulette with you data already, add a USB interface and your playing with 2 chambers loaded. OK so that wasnt about btrfs, more of making a point that even after something is marked stable and accepted you need to take a hard look at criticality. Are the metrics coming back real or fudged due to caching tricks? If so what are the ramifications? What are the recovery options? Is there a specific gain you are looking for that equates to an acceptable risk? These are all things that should be looked at in choosing a file system. 'zomg teh newerest laterest' folks are crash test dummies. To be honest for my systems I should probably be running EXT2 in data ordered mode. I dont, but I know why I dont. There are physical limitations on write speeds that can not be circumvented, fun FS caching tricks can make it appear higher, but they are still tricks, and seriously how many of us are using 16TB single partition storage? |
Steven_Rosenber Aug 06, 2010 6:45 PM EDT |
I've been wary of ext4, and I still use ext3 on my backup drives, but with Fedora 13 I've been running ext4. No problems so far. |
gus3 Aug 06, 2010 7:09 PM EDT |
Try this on your ext4 volume (but not on important data!): 1. Unmount it. 2. Run "e2fsck -C 0 -D -f -y /path/to/device". If it reports no errors fixed, stop. The rest of these steps won't work. 3. Re-run the same command. 4. Note how "fixed" errors still pop up. Bad, bad, bad! I've observed this on Slackware 13 and Fedora 13. However, I don't know how to get this to happen consistently, so I don't know how to file a bug report on it. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!