News for hackers. Stuff that matters.

A comment on Scripts for Btrfs Maintenance. Parent comment

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...

[ Parent | on HN ]
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.

[ Parent | on HN ]
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.

[ Parent | on HN ]
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.

[ Parent | on HN ]