Validation: The mother of all evils
Only for file systems designed in around 1978, upgraded in 1987, which suffer from "scalability" limitations
One of the major setbacks AmigaOS 3.1.x users will face, is that along with the benefits of large drives and newer FFS support, big volumes will definately become very common. This means that if you had to wait for quite some time before to get your volumes validated, on lets say a 500MB partition, just imagine how long will it take with a 20GB partition (and I am being really modest here).
The FFS is not well equipped to handle volumes that large.
For example, the file system startup itself will take a very long time, because once a volume is mounted, the OFS/FFS/DCFS mode requires that all the currently allocated blocks on the disk are counted. The file system literally keeps counting bits.
File sizes beyond 2,147,483,647 bytes are not entirely safe to use although in theory they might just work if you only read such files sequentially. More trouble begins if you write more than 4,294,967,295 bytes to a file. This might actually work, but the byte counters in the file header block will roll over which breaks the relationship between the reported file size, the number of blocks used as reported, the number of blocks actually used by the file. Disk repair utilities might just truncate such files during the repair operations.
Finally, the file system cannot manage volumes larger than 4,294,967,295 blocks, and it might not even know that it can't handle more than that.
The validation process itself is "just" one problem here, and by comparison, it only gives you trouble rarely, whereas the limitations of the daily file system operations are giving you trouble on a much more permanent basis
I know, clever users will still partition drives in a more reasonable manner, so that volumes dont get that large, but then is that a real solution?
Given the constraints (creaky design which did not evolve and improve over time, practically impossible to fix), this is what users tend to do. They cope by limiting what they can do with the file system and the media the file system uses. This started way back when Amiga hard disk drives became much larger than the comparatively "safe" 4 Gigabytes. If memory servers, that was in 1996.
And please dont tell me this is no problem, as this has been happening for decades, despite all AmigaOS developers not visualizing it as an issue.
Of course it's a problem, it's just quite difficult to fix. Actually, I have a cunning plan how to add journaling with write-ahead logging to the FFS in a backwards-compatible manner which will resolve the validation issue (well, up to a point). This is a long-term project, though. At the moment I'm working on something else that deals with file system defect repairs and data recovery.
My proposed solution is a cli command to tweak FFS behaviour:
C:Validate
Changes how the filesystem manages write errors.
OPTIONS
oneatatime -Validates/fixes volumes one at a time.
novalidate -Ignores any FS errors and doesnt validate/fix them.
prevent -Attempts to trap the reset signal so that FS write corruption may be prevented.
warn -Detects FS errors and gives a warning but doesnt perform any repair/validation action at all.
fix -This is the default FS behaviour: If FS error occurs, all volumes are mounted read only and validate/repair starts on all of them.
waitfix -If FS error occurs all volume activity is halted until validate/repair is finished. Then volume activity resumes as usual.
ask -If error in the FS occurs, the user is asked to either validate/repair, ignore or mount readonly.
some options can be combined:
the "prevent" option can be combined with any other one.
"oneatatime" can be combined with "waitfix", "ask" and obviously as mentioned before, with "prevent".
I'd say that this would be doable from a technical point of view. Not so much from the point of view of available manpower to make it happen right now, as far as I can tell
