Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs

[mark45]

The smug arch user and his latest and greatest.

[DeeK]

To those of you proudly using if for some time, what are your experiences? Is the low-disk-space handling decently fixed yet? How long since you've last hit a btrfs bug (even if corrected)?

Have been using btrfs for nearly a year now, starting with kernel 3.10, and now on 3.14. Using it on a secondary backup system, making use of the snapshot and compression features to keep a rolling 60 day backup history of data files and server configurations for around 10 production servers. Basically, it's a time saver. Saves me having to dig through the proper backups to restore something changed in the last 60 days.

Wanted to try it out on something that wasn't mission critical, but still useful. This was the perfect scenario. Have to say, I'm impressed. Works beautifully, and hasn't had a hiccup. I'd recommend it, at least for the usage patterns I've put it under.

[Pseus]

For traditional HDD usage I've found XFS/Ext4 serve my needs better. I keep a Btrfs loopback device for cases where CoW is a must. Going the way of SSDs or RAID Btrfs might be a better choice.

Edit: disclaimer: the main reason I stopped using Btrfs for root was that it caused horrible temporary freezes in certain use scenarios. This was a long time ago, I may give it a try again sometime.

[GreatEmerald]

My experience is pretty much the same as Ericg's. The last bug I ran into was around half a year ago, and it was btrfsck giving out false positives after forced reboots. It was fixed fairly quickly and obviously no harm was done.

There was a bug that I didn't run into, but it was mentioned on the wiki where balancing on some old kernels would cause something bad to happen, but the fixes to that were backported even into LTS kernels quickly enough.

The only issue I do have is that bcache reportedly doesn't work well with Btrfs yet. It might work, but nobody tested it enough and so it might still have issues. I wanted to make my SSD into a bcache drive, but ended up simply putting everything but /home on the SSD (which is still pretty great, those 3 second boot times are nice).

Wouldn't go back to EXT4 unless for devices where I don't care about their data (netbooks and such).

[GreatEmerald]

/dev/sda2 on / type btrfs (rw,noatime,ssd,space_cache)

Am i doin' it rite? </smuggest Gentoo user response>

You don't have compression on! lzo has worked well for all my needs so far.

[ImNtReal]

Is the low-disk-space handling decently fixed yet?

No. Disk space handling is still a huge pain with it. I was hoping to setup quotas thinking that might help the situation, but when I tried a while back I ran into a wall. I've been chugging along with it for a while, now. I've had to rebuild my two-SSD RAID-1 system volume once, and my big multi-disk RAID-10 set a couple of times, now. I keep hoping it will get there, but to this point I wouldn't put it on a production system. RAID-5/6 would be nice to test out, but the last time I checked, it still doesn't support scrubbing those.

[arrow]

You don't have compression on! lzo has worked well for all my needs so far.

Try:

noatime nobarrier nodatacow nodatasum ssd ssd_spread compression=lz4

LZ4 patch to compression... this will do a fast fs, but corruptions everywhere. For enthusiasts, is interesting try it some day...

[psychoticmeow]

/dev/sda2 on / type btrfs (rw,noatime,ssd,space_cache)

Am i doin' it rite? </smuggest Gentoo user response>

Nope, you don't need to specify ssd as it's autodetected, and space_cache is enabled by default.

[Luke]

There is one disadvantage to COW

With copy on write, it is not possible to shred (secure overwrite) a file in place as each rewrite goes to different disk space. I use secure erase utilities even on encrypted filesystems as part of defense in depth when they will work. You can't shred anything on flash because flash also does not rewrite to the same physical location, but things like camera cards and small SSD's can usually fill all free space with random numbers in reasonable time.

I hear you can disable COW on btrfs, might try this for boot partitions simply because one of the NSA exploit modules for hard disk firmware atacks had no Linux modules (to emulate /boot) more recent than ext3 when the EFF captured one of their catalogs of attack hardware. They probably have ext4 by now, but possibly not btrfs.

[fscan]

Using it for ages too (arch linux) .. never had any problems until recently. On kernels >=3.15 my raid1 home partition sometimes hangs shortly after boot (all writes go to timeout, other paritions, also btrfs, work).
Reported it 2 months ago on bugzilla, no response. Stuck on kernel 3.14 for now.