> how hard it is to implement a modern filesystem that won't eat users' data.
Why is that so hard? Because of edge-cases? Caching/Timing considerations?
Why is that so hard? Because of edge-cases? Caching/Timing considerations?
How hard this is, it depends on the filesystem. Something like FAT, for example, is pretty much designed for ease of implementation, with few edge cases. Modern filesystems are not like that at all, the data structures are very complicated, so they must be extremely well tested before they are good enough to use. That would probably require an fsck to check for subtle inconsistencies; in the case of APFS you can use mine, but it's still very incomplete. Apple's published fsck is not very thorough.
As an example of the kind of problems to expect, I recall a bug in the Linux HFS+ driver. If you had a drive with lots of short filenames and lots of long filenames, and you started deleting the short filenames, eventually you would lose half of your files. This kind of things happen because HFS+ has variable-length keys in the index nodes of its trees, so deleting a record may trigger a complicated cascade of node splits. APFS inherited this feature, and it was very annoying to implement.
But HFS+ is very well documented; APFS is not, and that doesn't help.
[0] https://www.theregister.com/2018/02/16/apple_file_system_bug...
• C being a shitty language that does not force or even encourage programmers to handle errors
• implementation knowledge about file system technology is generally stuck in the 1990s
• disk controller hardware lying to the OS to make them appear more performant than they really are
visit https://danluu.com & ctrl+f "files"
I don't see where this is coming from. Most of the world's top filesystems are written in C, and they work just fine. Maybe other languages could get better results, but it's hard to say with so little data.
> implementation knowledge about file system technology is generally stuck in the 1990s
If you are talking about me, that might be true, I'm relatively new to this and still learning. But there's definitely people out there with some serious "implementation knowledge". And tools like xfstests did not exist in the 1990s, that makes a huge difference.
And for specific examples of options with better safety records, then sure Rust would be one possibility, as would Ada, or Frama-C if you need to stick with C.
> I'm simply disputing your general claim that moving away from C would not help
I never said such a thing, I said we don't know. As always, in theory, there is no difference between theory and practice; in practice, there is.