Next component: The FastFileSystem.
There is not really much to say as we haven't found any bugs. There are two slight improvements:
First, the FFS stores now all the bitmap blocks contiguous instead of interleaved with the bitmap list blocks. This has the (potential) advantage that a future FFS implementation may read them in one single go. We currently read them one by another. That's ok, but not quite as fast as we could. Still, it's faster than the previous version of the FFS as the code no longer allocates the memory for each block individually, reads it, and then releases it again, so AllocMem() and FreeMem() were stressed quite a lot. Instead, the FFS makes one allocation, and then keeps it.
Second, the FFS supports now ACTION_DIE, a new dos packet, that indicates to the file system that it should shut down if possible, releasing all its resources. It remains mounted, but with no handler task attached. This is one of the core ingredients to the new "Mounter" tool which mounts partitions from the RDB, and - as part of its job - also unmounts previous file systems on the same physical layer. With ACTION_DIE, it can release many more resources and does not have to keep copies of the file system lie around in memory, doing nothing.
Actually, ACTION_DIE was already integrated into CrossDos and the CDFS in 3.1.4, so we just completed a job that was started long before. It was a bit more tricky for the FFS because the FFS is heavily multi-threaded, and its code flow is not exactly easy to follow.
To trigger an ACTION_DIE manually, the "mount" command received a new option: "SHUTDOWN". Thus, "mount df0: SHUTDOWN" un-mounts df0: All provided, of course, that there are no locks open on DF0:, no files are open, and the FFS is idle as you would otherwise "pull the rug under its feet".
"Assign Dismount DF0:" is quite different. All it does is that it makes the mounted file system invisible to the dos.library and hence to programs that want to open files on it, but it keeps running in the background, potentially modifying the disk, and potentially (still) reacting on programs that talk to it. Thus, if a program still accesses the disk, "Assign Dismount" will not stop such programs, but the program will continue to operate. If you mounted a different disk layout on the same drive, this will cause quite some desaster.....
So the old rule still applies: RDB is not for removable media. Mount them with "SuperFloppy = 1", and no RDB on them, and the FFS will take care about the disk geometry itself and will size itself accordingly.
Thus, a safer way to un-mount a partition is first to attempt a "mount shutdown", and if that worked, kick the mount out of the system with "Assign dismount". Unfortunately, the latter is still not quite clean as it cannot reclaim the memory for the actual DosNode (i.e. the information on the disk in the dos.library) as there are multiple ways how it could have been allocated, but at least the major part of the memory and resouces is then cleanly released.