On Wed, Jul 13, 2022 at 01:16:37AM -0700, Linus Torvalds wrote: > > Can we please all agree that this code is too obscure for its own good? Oh, there's no denying that, or that the API is .... poor. The problem is that touching this code has a very high validation burden. Like Darrick, I'm familiar with this code because we were the poor shmucks who decided dedupe needed data integrity testing before we could support it in XFS. Three months of finding and fixing data corruption after data corruption in the ioctl/vfs layers and tens of billions of fsx ops later... ... and the code has really not changed very much since then. That's the fundamental problem with rewriting this code - validating that changes have not introduced new data corruption bugs on XFS, btrfs, NFS and other idedupe supporting filesystems is time consuming and resource intensive. And it can't be skipped, because corrupting user data is even worse than breaking userspace applications (i.e. you can fix the kernel so the apps run again, but corrupted data is gone forever). So while the code might be somewhat inscrutible for outsiders with no familiarity of the dedupe/clone APIs or it's required behaviours, it works as advertised and doesn't corrupt data. Hence for the past few years the rule "don't try to fix what ain't broke" has applied - we've all got plenty of stuff that is actually broken or deficient and needs to be fixed to deal with first.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
