mcc"Due to potential legal incompatibilities between the CDDL and GPL, despite both being OSI-approved free software licenses which comply with DFSG, ZFS development is not supported by the Linux kernel"
✧✦Catherine✦✧@mcc been that way for decades now
@whitequark I have a new hard drive I intend to use primarily for backup and I am currently considering BTRFS or ZFS for the Linux part instead of ext4 (because I hear they can do some thing of storing extra error-checking data to protect against physical disk corruption). In your view, if I intend to use mainline Debian indefinitely, will BTRFS, ZFS, both, or neither give me the least pain getting things working?
@whitequark A few people are commenting on BTRFS reliability problems which is weird because I thought the whole point was to be "the more reliable fs". Debian's wiki links to this bewildering compatibility table that looks like a bunch of stuff I don't care about (the only features I care about are reliability, and some of zfs's auto-backup stuff sounded compelling) but the weird "mostly ok" line around defragmentation/autodefragmentation worries me a little https://btrfs.readthedocs.io/en/stable/Status.html
Jernej Simončič �@mcc @whitequark I've been using btrfs for years without any problems, however I also never used the known to be problematic RAID5/6 support.
Nogweii S@mcc @whitequark I've been running btrfs on servers for years now, no filesystem bugs so far. (One issue had arisen around power being cut leading to some data corruption but that wasn't btrfs' fault)
@nogweii @whitequark i thought the entire point of a journaling fs was that cutting power doesn't lead to data corruption (unless the corruption was at the app level I suppose)
Ayla@mcc @nogweii @whitequark it doesn't *if the hardware upholds its end of the bargain*. no fs can protect against hardware that does not fulfill the guarantees its supposed to provide, and the only corruption I've had in btrfs was indeed due to faulty hardware. Btrfs has self-validation features so when faulty hardware breaks things btrfs is noisier about it than many fses, and that leads to a perception that it is worse when its just better at knowing what's broken.
Hugo Mills@mcc @nogweii @whitequark btrfs isn't a journalling FS -- it's copy-on-write, which is subtly different.
The problem with unexpected power-off is when the hardware lies. btrfs requires that when the disk says that data's hit permanent storage, it really has. In some cases of buggy firmware, disks can pass a write barrier while the data's still only in cache. With a power-fail, that can lead to metadata corruption, because the FS has updated the superblock, pointing to an incomplete transaction.
@darkling @nogweii @whitequark I see. But it seems like that would be no greater a problem for BTRFS than ext4.
"it's copy-on-write, which is subtly different"
Does it have different performance characteristics? Intuitively it seems like it must but I can't really justify the idea it does moreso than modern journaling/autodefrag
@mcc @nogweii @whitequark I don't know about performance. I can describe the algorithm.
Due to the way it works (the copy-on-write part), a lost write is going to effectively drop an entire page of metadata, rather than simply not updating an existing page. It *never* writes updated data in place, except for the superblocks, which have fixed locations. So the damage in the missed-write case is rather larger than with non-CoW FSes
b@mcc @whitequark i have a friend who despises btrfs and has had so many problems with it but i've been using it for years and it's always worked pretty well so idk? i think it can be a bit janky and confusing sometimes but imo a lot of that is just because it's so different from traditional filesystems
the one thing i can think of is that i've recently been getting some qgroup related warnings on my server that i'm not sure the cause of, i ran the command the message recommended to address the issue last night so we will see if it makes the messages go away
the one thing i can think of is that i've recently been getting some qgroup related warnings on my server that i'm not sure the cause of, i ran the command the message recommended to address the issue last night so we will see if it makes the messages go away
@mcc @whitequark You don't want to defrag something that's been snapshotted (because it breaks the reflink copy, and you end up with ~twice the data usage). It's stable; it just has this unexpected side-effect that many people don't know about until they try it.
you're all idiots@mcc @whitequark I've worn out* I think three sets of HGST disks on btrfs over the years and have had little problems.
* from old age in SMART data
@mcc @whitequark No data loss except once I ended up having a directory that would crash the os if accessed. I had been migrating file systems with DD onto new disks since the first usable versions of btrfs. Eventually on the next set of disks (maybe 8 years ago) I did a clean mkfs and never had any problems since.
@mcc So it's stable enough but it does have some issues with database files which don't do well with the btrfs data model, leading to massive fragmentation caused by the random writes.
This is not an issue if you're copying files whole like for a backup.
This is not an issue if you're copying files whole like for a backup.
@mcc for a single backup disk you would probably be better off with xfs or ext4 simply because there's no need for the btrfs special features.
If it ever comes to data recovery then these two will be better known, and easier on the recovery process.
If it ever comes to data recovery then these two will be better known, and easier on the recovery process.
@mcc except if you're backing up a btrfs to btrfs. It then becomes possible to make snapshots on the master and then stream those to the backup, recreating snapshots there.
keithzg@whitequark @mcc Honestly the only times I have had problems with BTRFS have been when I have done deeply silly things, and even then it's always been recoverable. Been running some big storage pools of slow-spinning rust for years and no trouble. And I have *terrible* luck!
Ryan Castellucci (they/them) 
@mcc @whitequark I have been burned by btrfs multiple times, and ZFS has been fantastic. 🤷