"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"
-
@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
@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.
-
@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?
@mcc @whitequark just my take but I consider ZFS aimed at arrays and such. Single drive I’m just not sure you’re going to get any benefit and it might actually be substantial worse.
-
@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
@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)
-
@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)
-
@mcc @whitequark just my take but I consider ZFS aimed at arrays and such. Single drive I’m just not sure you’re going to get any benefit and it might actually be substantial worse.
@petrillic @whitequark do you think there is an advantage of BTRFS over ext4 for a single drive, single computer, non RAID, my sole/primary goal is "i want it to last as long in a room-temperature drawer as possible"?
-
@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
@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 -
@petrillic @whitequark do you think there is an advantage of BTRFS over ext4 for a single drive, single computer, non RAID, my sole/primary goal is "i want it to last as long in a room-temperature drawer as possible"?
@mcc @whitequark I think this is a scenario where external influences are critical. I would use ext4. Mostly because its quirks are well known and if I had to recover it, there’s tons of resources all the way down to physical recovery companies.
BTRFS I think is missing all that infrastructure.
-
@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
@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.
-
@mattdm @jernej__s @whitequark so all i need is for the AI bubble to pop and the WB deal to go bad, and things will be ok?
@mcc @mattdm @jernej__s @whitequark@treehouse.systems Thus reducing to a previously-had problem
-
@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)
@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.
-
@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
-
@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?
@mcc btrfs
my headmate, who is obsessive over data integrity, runs btrfs on her NAS with zero issues. it has nice things like snapshotting and such. the reputation btrfs has dates back to many years ago and i don't think the issues people distrust it for have mattered for quite a while
-
@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?
AIUI, ZFS really requires multiple drives to be effective.
You might gain a little value from extra checksums on file system blocks on a single drive, but if those checksums ever start failing on a hard drive there is a high likelihood that most of the drive is about to fail completely.
I had researched ZFS a fair bit as I planned to build my own FreeBSD NAS around 3-4 drives in ZFS, but eventually decided to buy an off-the-shelf ZFS NAS from the TrueNAS people.
