Btrfs Gets Fixes For Linux 4.9, Linux 4.10 To Be More Exciting

[pal666]

Although I've been running btrfs for a number of years now, and haven't had any issues for, again, a number of years, I'm really beginning to lose interest in it and am looking forward, instead, to upcoming xfs changes (snapshots! data scrubbing! COW!)

funny, you lose interest in btrfs and looking forward to xfs adding some of btrfs features. so half of btrfs in future is more interesting than full btrfs now?

[pal666]

Is there really any practical advantage of using BTRFS over ZFS at this time?

btrfs is not obsolete
btrfs exists on linux
btrfs can change its size

[Cyber Killer]

Native per-volume encryption is pretty high on the list for me.

+1

Ever since I had a major failure of my laptop filesystem while being in travel abroad & had to use a livecd for a week, I had to get back to using ext4. Btrfs on luks encrypted lvm apparently is not a good idea. Native encryption in btrfs would help.

[bobwya]

s/btrfs/zfs/g

[timofonic]

XFS has more fame about reliability, Btrfs have been a clusterfsck.

They need to make something really BIG to make people recover confidence in BtrFS and not just in code (this project is losing momentum in an exponential way) but in geek-aware PR too!

[RussianNeuroMancer]

What about parity code issues? Is there ETA when it will be fixed?

[AndyChow]

Just when I was ready to get back into BTRFS... I've always had problems with it. It "sounds" pretty straight-forward to create a FS. I mean, it's blocks, properties of blocks, and then methods on those blocks. I'm sure it's gotten better, but when you see "Total: (39) commits (+1714/-1222)", makes me want to stay away from said FS.

I've eventually corrupted every BTRFS array I've ever had.

[GizmoChicken]

Btrfs on luks encrypted lvm apparently is not a good idea. Native encryption in btrfs would help.

I agree that native encryption in btrfs would be great. But as for Btrfs on luks, I've been using it (without lvm) for nearly a year on my laptop and backup drives, and I haven't had any file-related problems.

[dcrdev]

I've been running a BTRFS raid 10 with 6 disks for about 6 months now - overall the file system itself seems fairly stable; I've not had any major issues - only thing I've encountered is on some kernels auto defrag spawns unexpectedly and hovers on 100% cpu usage.

For me something that's currently making me contemplate switching back to xfs/mdadm is that btrfs doesn't seem to play nicely with systemd one bit - in particular raid setups, due to multiple disks having the same uuid systemd often complains and maybe 50% of the time hangs at boot; not something that is ideal with a server being managed from another location.

There is an ongoing bug filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1354131 but no one seems to care about it.

[starshipeleven]

It "sounds" pretty straight-forward to create a FS. I mean, it's blocks, properties of blocks, and then methods on those blocks.

That's kind of total bullshit tho. Any half-assed programmer can re-implement something like FAT32 in a week tops, but any serious filesystem (say ext4, no need to get to btrfs) is quite a bit more complex than that.

I'm sure it's gotten better, but when you see "Total: (39) commits (+1714/-1222)", makes me want to stay away from said FS.

Then you can stay away from ext4 and xfs too, as they do code cleanup and end in similar commit situation too.

I've eventually corrupted every BTRFS array I've ever had.

Stop corrupting your arrays.