Filesystems and crash resistance [LWN.net]

Filesystems and crash resistance

Posted May 22, 2019 15:40 UTC (Wed) by rweikusat2 (subscriber, #117920)
In reply to: Filesystems and crash resistance by jake
Parent article: Filesystems and crash resistance

This text is ten years old and entirely generic. Additionally, the conclusion

This is because it is very difficult to map backward from a given file to the dirty file system blocks needing to be written to disk in order to create a consistent file system containing those changes. For example, the block containing the bitmap for newly allocated file data blocks may also have been changed by a later allocation for a different file, which then requires that we also write out the indirect blocks pointing to the data for that second file

is just plain wrong. Nobody asked for "a consistent filesystem containing those changes" aka "for a sync" (ultimatively). The request was that changes to a specific file are to be made persistent. Obviously, the 'easiest' way to implement that is to ignore this and write everything. Which filesystems did this back then? Which filesystems didn't? And what's the situation today? This could be useful information for choosing a particular filesystem.

to post comments

Filesystems and crash resistance

Posted May 23, 2019 18:41 UTC (Thu) by matthias (subscriber, #94967) [Link]

Writing everything is the awfully slow solution that is not wanted. The problem with writing out bitmap blocks for unrelated files is, that -- if a crash would happen in the wrong moment -- the metadata would be inconsistent. And this is what should never happen. Of course, not everything needs to hit the disk, but the subset that hits the disk has to be consistent. Therefore it is problematic if accidentally some unrelated metadata changes are written.

Filesystems and crash resistance

Posted Jun 21, 2019 3:47 UTC (Fri) by nivedita76 (subscriber, #121790) [Link]

What do you see as the difference between "consistent file system containing those changes" and "changes to a specific file are to be made persistent"? Those "changes to a specific file", the one that got fsync'd are exactly what that first quote is referring to.