> Case study: recovery of a severely corrupted 12 TB multi-device pool, plus constructive gap analysis and reference tool set #1107

Please don't be btrfs please don't be btrfs please don't be btrfs...

▲

curt15 an hour ago | parent | next [-]

Where are all of the ZFS corruption stories? Or are there simply fewer of those?

	▲	Neikius an hour ago \| parent [-]
		Not sure about the stats, but it does feel like there are fewer. So from what I know encryption and sending fs state had bugs in ZFS. And on btrfs anything above raid1 (5,6 etc) has had very serious bugs. Actually read an opinion somewhere (don't remember where) raid5,6 on btrfs cannot work due to on-disk format being just bad for the case. I guess this is why raid1c3/c4 is being promoted and worked on now?

▲

toaste_ 5 hours ago | parent | prev [-]

I mean, the only other option was bcachefs, which might have been funny if this LLM-generated blogpost were written by the OpenClaw instance the developer has decided is sentient:

https://www.reddit.com/r/bcachefs/comments/1rblll1/the_blog_...

But no. It was btrfs.

As a side note, it's somewhat impressive that an LLM agent was able to produce a suite of custom tools that were apparently successfully used to recover some data from a corrupted btrfs array, even ad-hoc.

▲

yjftsjthsd-h 5 hours ago | parent [-]

It could be ZFS. I'd be much more surprised, but it can still have bugs.

▲

praseodym 4 hours ago | parent [-]

ZFS on Linux has had many bugs over the years, notably with ZFS-native encryption and especially sending/receiving encrypted volumes. Another issue is that using swap on ZFS is still guaranteed to hang the kernel in low memory scenarios, because ZFS needs to allocate memory to write to swap.

	▲	badgersnake 4 hours ago \| parent [-]
		The zero copy that zero copied unencrypted blocks onto encrypted file systems was genius. It’s almost like they don’t test.