Btrfs In Linux 4.2 Brings Quota Updates, Many Fixes

[phoronix]

Phoronix: Btrfs In Linux 4.2 Brings Quota Updates, Many Fixes

Adding to the already lengthy list of new features for Linux 4.2 is the Btrfs file-system updates that were sent in today by Facebook's Chris Mason...

http://www.phoronix.com/scan.php?pag...ux-4.2-Updates

[zanny]

I'm a masochist, so I like to throw btrfs on consumer computers and see if it blows up in my face. It did again today - another corrupt ctree root bug, the kind of oh so go fun unrecoverable corrupt log / bad checksums / whole partition is screwed horror. This person even had a UPS to keep the damn drive from having inconsistent state bugs when the power goes out that I used to know were extremely common. She gets a recovery disk image from last Friday on ext4 this time.

But I generally just say "run BTRFS until it goes down in flames, then take a year break from it". So July 2016 is when I'm next looking to ever fathom putting btrfs on another end user computer again. I'll keep running it on my drives (with ample backups) because I cannot believe I cannot get data integrity checksums with any other in kernel filesystem, but I kind of like those too much to let catastrophic failure twice a year hold me back.

Seriously Facebook, do a code audit on your adopted bastard son of a file system. Or write it in Rust. This kind of shit cannot break this much after, what, six years of development? Its pretty silly at this point. Startups go on and on about shipping a minimal viable product in six months.

[nanonyme]

I'm a masochist, so I like to throw btrfs on consumer computers and see if it blows up in my face. It did again today - another corrupt ctree root bug, the kind of oh so go fun unrecoverable corrupt log / bad checksums / whole partition is screwed horror. This person even had a UPS to keep the damn drive from having inconsistent state bugs when the power goes out that I used to know were extremely common. She gets a recovery disk image from last Friday on ext4 this time.

But I generally just say "run BTRFS until it goes down in flames, then take a year break from it". So July 2016 is when I'm next looking to ever fathom putting btrfs on another end user computer again. I'll keep running it on my drives (with ample backups) because I cannot believe I cannot get data integrity checksums with any other in kernel filesystem, but I kind of like those too much to let catastrophic failure twice a year hold me back.

Seriously Facebook, do a code audit on your adopted bastard son of a file system. Or write it in Rust. This kind of shit cannot break this much after, what, six years of development? Its pretty silly at this point. Startups go on and on about shipping a minimal viable product in six months.

Did you go file a bug and talk with the devs in IRC? I've found Btrfs has a rather helpful set of people behind it

[Guest]

Did you go file a bug and talk with the devs in IRC? I've found Btrfs has a rather helpful set of people behind it

I have the same experience, btrfs devs are very helpful, but the guy is right about btrfs breaking a whole lot, especially if you are using it's features and non-standard configurations (raid, snapshots, ... ).

[rdnetto]

I'm a masochist, so I like to throw btrfs on consumer computers and see if it blows up in my face. It did again today - another corrupt ctree root bug, the kind of oh so go fun unrecoverable corrupt log / bad checksums / whole partition is screwed horror. This person even had a UPS to keep the damn drive from having inconsistent state bugs when the power goes out that I used to know were extremely common. She gets a recovery disk image from last Friday on ext4 this time.

I used to run into ctree bugs every so often a few years ago, and I found the best solution was to only install it on RAID0 setups. The reason this works is because btrfs mirrors the superblock & metadata, so it can be recovered even if lost, but you still get the full capacity. I haven't run into those bugs in a while though, so it seems like it's gotten a bit better.

I have the same experience, btrfs devs are very helpful, but the guy is right about btrfs breaking a whole lot, especially if you are using it's features and non-standard configurations (raid, snapshots, ... ).

I've been using snapshots quite heavily, and pretty much the only related bug I've run into is the performance hit for mechanical drives. (That, and some weirdness with btrfs send/receive.)

RAID0 and RAID1 seem to be in good shape as well, but I wouldn't trust RAID5/6 just yet.

[rleigh]

I have the same experience, btrfs devs are very helpful, but the guy is right about btrfs breaking a whole lot, especially if you are using it's features and non-standard configurations (raid, snapshots, ... ).

Definitely. I gave up on Btrfs last year after it losing my data too many times. Unrecoverable RAID arrays (corrupted all the disks in the array!), kernel panics/oopses and more recently repeated unbalancing to the point of unusability. I'm still hopeful it will become usable, but it will take a while to regain my trust. But the one thing I expect from a filesystem above all else is data integrity, and it's failed on me too many times now.

Since the features it offers are good and desirable, I've ended up using ZFS. It supports the same nice stuff Btrfs does, plus a whole lot more. It works pretty well on Linux--I migrated my Btrfs filesystems/subvolumes to a ZFS zpool/filesystem setup and it worked well, but I ended up moving the disks into a FreeBSD 10.1 NAS since its support for ZFS is quite a bit more advanced (later zpool versions, more features and better integration with the system). I'd have to say I've been impressed by it. I've been thrashing it for 18 months now and it's been absolutely solid on both Linux and FreeBSD.

[AndyChow]

Every single Btrfs filesystem I've had has eventually become corrupt/unmountable. One problem or another. Luckily, never lost any important data. I never reached out to the devs directly. They may be friendly, but their documentation is lacking. A lot is outdated, gives commands that will break your system. You search and search, you find an email from a dev saying "that's deprecated since version so and so, don't use it anymore".

The devs might want to spend more time keeping the documentation up to date, they might spend less time debugging errors end-users get.

[Ansla]

How full were your drives when those problems apeared? I'm usig btrfs on 3 different machines for several years now and never had one fail. But I try to keep at least 30% free space on each drive. That is harder on the SSD (that one is currently 93% full), but trivial on the HDDs.

[rleigh]

How full were your drives when those problems apeared?

I've had the filesystem become completely unbalanced at less than 10% utilisation! It appears not to be the capacity used that triggers this, but rather the amount of I/O you are doing, possibly also coupled with how many snapshots you are creating and deleting. I can completely unbalance a terabyte Btrfs filesystem within 36 hours of sustained disk activity with an average space utilisation of around 1-2%, 10% transient peak usage.

And for the unrecoverable dataloss issues I've had, I doubt free space played any great role there. It trashed one disk of a mirror when a SATA glitch occured, and it trashed the other disk when the system was rebooted to add insult to injury. To make it worse, the other half of this disk pair were ext4 on mdraid; this continued working without a hitch during the initial glitch, and the array was transparently resynched on reboot after I'd swapped the SATA cable. This was some time ago, and I think this particular issue was resolved a good while back, but I shake my head in despair when Btrfs is claimed to be ready for production. This has been claimed continually for years, but it's still too risky to commit to it.

[linner]

BTRFS development has been a lot like ext. Is it developed by some of the same people? I don't know but ext took many, many, many, many years to become reliable and that was after it was declared stable and ready for prime-time (hell, even now I don't consider it all that reliable). I remember back in the early 2000's trying to create a large (for the time) multi-terabyte ext filesystem and the mkfs itself would crash... couldn't even create the filesystem. Several times in the 90's I had lost complete ext filesytems due to random corruption for no reason even with no hardware failure. I switched to XFS in the late 90's after losing those ext systems. XFS was somewhat buggy back then but still better than ext. Nowadays XFS is rock solid, I have never lost data on it in 15 years even with multiple hardware failures and heavy abuse (I run software RAID6).

With that said, XFS has performance issues on some of my hardware. I have a 8TB RAID6 XFS array on one server and the whole machine will often hang for 15-20 seconds when doing heavy write I/O to the filesystem. I tested BTRFS on the same machine and it was way better. However, I don't trust BTRFS enough for critical large systems and I have this feeling it will always be somewhat unstable like ext is. Which is a shame because I really want to use it. I do use it on a few web servers because I need the BTRFS features like snapshots for running containers but those machines are small and have their BTRFS filesystem mirrored to an offsite server so if it loses the filesystem it's no big deal.

I don't care for ZFS all that much, BTRFS is better usage and feature-wise. I just wish BTRFS wasn't so unstable and slowly developed.