Originally posted by cl333r
View Post
If you want to make something like FAT then it's much more straightforward. Low performance, few features, and no assurance of integrity after a crash or power outage.
Implementing features like journaling and CoW without shooting yourself in the foot means dealing with really complicated order-of-operations. Made worse by unknown progress in the case of a crash or power outage. Add to that the fact that the easiest solutions (eg. global lock on the filesystem tree) are really bad for performance. Then of course this is with multiple simultaneously accessing programs, all trying to read and write files at the same time.
The fact that filesystems are persistent is also raises the stakes, as a problem with the fileystem will silently corrupt data in the background and can't be simply wiped out with a reboot. This alone is enough to keep filesystem developers (and users) worried.
EDIT:
Oh, and of course NONE of that even mentions trying to do integrity checking and *correction* on data. Correcting data errors means storing redundant copies or enough parity data, and routines for checking/fixing.
And then of course a problem could happen anywhere, including the structures outside the data that describe the filesystem and it's structure. You can't blindly trust *those* and have to be able to detect corruption there too, and recover from it.
Comment