7 ms·

I can echo/support this claim - I wandered down the same rabbit hole. It doesn't even get much better with many drives and avoiding the docs/tooling BTRFS arr

I can echo/support this claim - I wandered down the same rabbit hole. It doesn't even get much better with many drives and avoiding the docs/tooling BTRFS arrays will consistently corrupt with my reset button -- RAID10 on gen4 NVMe drives... while LVM/dm-raid + traditional file systems are absolutely fine

xtracto 3y ago
>BTRFS arrays will consistently corrupt with my reset button YES!!! Sorry to beat a dead horse, but it has been so frustrating for me. I thought I did something wrong, like, how could the partition break for doing nothing! Where did I fucked up? I cannot imagine the experience with a RAIDed BTRFS array shudders
- phire 3y ago
  I had a BTRFS raid corrupt because one of my HDD had a firmware bug and was silently discarding writes. Sure... HDDs shouldn't do that, but it's literally the job of a BTRFS raid to protect me from such issues. The data was all still intact on the other drive. I could see it with dd, but BTRFS refused to read it.
curt15 3y ago
Isn't copy-on-write supposed to be inherently resilient to crashes[1]? Why would btrfs be more susceptible to resets than traditional filesystems? [1]: https://unix.stackexchange.com/questions/634050/in-what-ways-is-the-cow-filesystem-an-improvement-over-the-journaling-filesystem https://unix.stackexchange.com/questions/634050/in-what-ways...
- bravetraveler 3y ago
  I doubt that because of the experience I just outlined In theory perhaps, but absolutely not in practice. Making things atomic is tricky.
- londons_explore 3y ago
  I think most of the bugs are in the drives themselves - doing things like claiming data is flushed when it is not. However, btrfs is a very fragile filesystem and any inconsistencies caused by the drive bugs tend to lead to it breaking and refusing to mount, whereas on other filesystems you'll just get a warning in dmesg. It doesn't help that btrfs developers refuse to work around drive bugs.
  - phire 3y ago
    > It doesn't help that btrfs developers refuse to work around drive bugs. The entire selling point of the filesystem is that it's resilient to data corruption. Drive bugs are just another class of data corruption.
yrro 3y ago
> BTRFS arrays will consistently corrupt with my reset button I know you don't want to get asked this, and I wouldn't if you'd just said "I tried this once a while ago and it happened", but if it's consistent... have you filed a bug?
- bravetraveler 3y ago
  It's a fair ask! I don't mind. It's occurred to me, but I expect a fair bit of push back; 'you abuse the array and expect it to... what?' I'm not really interested in debating that, and it's remarkably easy to get hung up on. I've floated this issue a few times unofficially and it's a constant stickler I know expecting coherency in this situation is a little silly, but BTRFS is notably less reliable/robust than the alternatives All in all... I'm avoiding a situation that may or may not occur, by not participating. Not saying it's a good thing, but it's easier for me to just use What Works
  - yrro 3y ago
    With properly functioning hardware (i.e., that doesn't lie to you when it says "that has been committed to durable storage") then metadata or data corruption following power loss is definitely a bug! It didn't even occur to me that you might get a different response. I'd be kind of annoyed if I went to the trouble of reporting a bug and got that response. But I'd also not assume it would end that way...
    - bravetraveler 3y ago
      With where we're at with SSDs chasing the performance dragon... I suspect some deception is at play! The DRAM caches are pretty hefty compared to metadata, so I wouldn't be surprised - though that's about my extent of understanding. Even then, though - other filesystems are certainly more durable, dealing with whatever these drives are doing. FWIW, this was with four Sabrent Rocket 4.0 Plus drives in RAID10 with 4K sectors. I'm not sure if these are particularly well known one way or another for deception/trickery They hold up just fine with either dm-raid or native LVM raid10 under more traditional filesystems (I tested EXT4/XFS, using the latter consistently)

xtracto 3y ago

>BTRFS arrays will consistently corrupt with my reset button YES!!! Sorry to beat a dead horse, but it has been so frustrating for me. I thought I did something wrong, like, how could the partition break for doing nothing! Where did I fucked up? I cannot imagine the experience with a RAIDed BTRFS array shudders

phire 3y ago
I had a BTRFS raid corrupt because one of my HDD had a firmware bug and was silently discarding writes. Sure... HDDs shouldn't do that, but it's literally the job of a BTRFS raid to protect me from such issues. The data was all still intact on the other drive. I could see it with dd, but BTRFS refused to read it.

curt15 3y ago

Isn't copy-on-write supposed to be inherently resilient to crashes[1]? Why would btrfs be more susceptible to resets than traditional filesystems? [1]: https://unix.stackexchange.com/questions/634050/in-what-ways-is-the-cow-filesystem-an-improvement-over-the-journaling-filesystem https://unix.stackexchange.com/questions/634050/in-what-ways...

bravetraveler 3y ago
I doubt that because of the experience I just outlined In theory perhaps, but absolutely not in practice. Making things atomic is tricky.
londons_explore 3y ago
I think most of the bugs are in the drives themselves - doing things like claiming data is flushed when it is not. However, btrfs is a very fragile filesystem and any inconsistencies caused by the drive bugs tend to lead to it breaking and refusing to mount, whereas on other filesystems you'll just get a warning in dmesg. It doesn't help that btrfs developers refuse to work around drive bugs.
- phire 3y ago
  > It doesn't help that btrfs developers refuse to work around drive bugs. The entire selling point of the filesystem is that it's resilient to data corruption. Drive bugs are just another class of data corruption.

yrro 3y ago

> BTRFS arrays will consistently corrupt with my reset button I know you don't want to get asked this, and I wouldn't if you'd just said "I tried this once a while ago and it happened", but if it's consistent... have you filed a bug?

bravetraveler 3y ago
It's a fair ask! I don't mind. It's occurred to me, but I expect a fair bit of push back; 'you abuse the array and expect it to... what?' I'm not really interested in debating that, and it's remarkably easy to get hung up on. I've floated this issue a few times unofficially and it's a constant stickler I know expecting coherency in this situation is a little silly, but BTRFS is notably less reliable/robust than the alternatives All in all... I'm avoiding a situation that may or may not occur, by not participating. Not saying it's a good thing, but it's easier for me to just use What Works
- yrro 3y ago
  With properly functioning hardware (i.e., that doesn't lie to you when it says "that has been committed to durable storage") then metadata or data corruption following power loss is definitely a bug! It didn't even occur to me that you might get a different response. I'd be kind of annoyed if I went to the trouble of reporting a bug and got that response. But I'd also not assume it would end that way...
  - bravetraveler 3y ago
    With where we're at with SSDs chasing the performance dragon... I suspect some deception is at play! The DRAM caches are pretty hefty compared to metadata, so I wouldn't be surprised - though that's about my extent of understanding. Even then, though - other filesystems are certainly more durable, dealing with whatever these drives are doing. FWIW, this was with four Sabrent Rocket 4.0 Plus drives in RAID10 with 4K sectors. I'm not sure if these are particularly well known one way or another for deception/trickery They hold up just fine with either dm-raid or native LVM raid10 under more traditional filesystems (I tested EXT4/XFS, using the latter consistently)