@Thomas Richter
@olsen
A journaling filesystem woulld certainly improve reliability.
But why not better kill more birds with one stone?
A versioning filesystem would be a much better overall solution, because not only it would allow the user to roll back to previous versions of files in case of system corruption, but it also means that if the filesystem does the work twice (comitting to disk), you at least do the job completely and not halfway like in a journaled filesystem, and also keep the benefit of having an older backup automatically.
The drawback, is of course, increased disk space usage, but is that really a problem in an Amiga system where files are really small in size and when storage media keeps getting bigger each day? And of course, you can also provide some algorithm for garbage collection when the amount of backup exceeds certain amount to free some space.
I don't quite see this yet. There is not a lot of wiggling room within the constraints the FFS on-disk data structures impose upon you. With a log of changes growing as write operations take place, you will have to deal more and more with managing disk space. This is where this file system design is really weak. There are no data structures to assist making optimal storage allocations under certain constraints (e.g. allocate closest to the tail end of the file, allocate closest to the file header block, pick the largest consecutive chunk of free space, etc.). As far as the FFS is concerned, the storage space is broken down into two big sets of almost identical size with no block preferable to the other.
If I remember correctly how log-structured file systems work, I can see how they are more attractive for use with SSDs. You rarely rewrite anything, if at all. The downside is that you have to deal with accessing the versions (through the existing file system API? we can't conveniently upgrade dos.library), representing the available storage space (minus the versioned data which could be reclaimed) and with scrubbing the log. You have to have all three, and each of these is quite challenging to implement.
By comparison, journaling with write-ahead logging would be much simpler to implement. It could be integrated into the metadata block access operations and the remainder of the file system, its APIs and data structures would remain unchanged.
I'd rather prefer to tinker with something that I understand up to a point, and which is extensible, than having to invent a big bag of new stuff, all of which would need a lot more testing just to make sure that it works as intended, including how it deals with defects.
