News for hackers. Stuff that matters.
Re:Scripts for Btrfs Maintenance by bravetraveler on Tuesday June 06, 2023 @09:42PM (#36221712)
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

Re:Scripts for Btrfs Maintenance by xtracto on Tuesday June 06, 2023 @09:58PM (#36221867)
>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

Re:Scripts for Btrfs Maintenance by phire on Tuesday June 06, 2023 @10:36PM (#36222159)
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.

Re:Scripts for Btrfs Maintenance by curt15 on Tuesday June 06, 2023 @10:45PM (#36222236)
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...

Re:Scripts for Btrfs Maintenance by bravetraveler on Wednesday June 07, 2023 @12:00AM (#36222667)
I doubt that because of the experience I just outlined

In theory perhaps, but absolutely not in practice. Making things atomic is tricky.

Re:Scripts for Btrfs Maintenance by londons_explore on Wednesday June 07, 2023 @05:47AM (#36224817)
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.

Re:Scripts for Btrfs Maintenance by phire on Friday June 09, 2023 @11:20PM (#36267247)
> 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.

Re:Scripts for Btrfs Maintenance by yrro on Wednesday June 07, 2023 @09:36AM (#36226628)
> 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?

Re:Scripts for Btrfs Maintenance by bravetraveler on Wednesday June 07, 2023 @10:24AM (#36227169)
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 - I know expecting coherency in this situation is a little silly, but BTRFS is notably less reliable

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

Re:Scripts for Btrfs Maintenance by yrro on Wednesday June 07, 2023 @11:41AM (#36228292)
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...

Re:Scripts for Btrfs Maintenance by bravetraveler on Wednesday June 07, 2023 @01:05PM (#36229723)
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)