Updates and things ...

[shenson@nyx10.cs.du.edu (Stephen Henson)]

Greetings,
          the Minixfs updater does one single Dcntl for MFS_SYNC. This
function is analagous to Unix sync() in that all drives are handled at
once. The reason for the path is because there is no way to send info
to a fileystem without a path of an 'owned' drive. However the update
demon needs access to Minixfs internals to be sure of finding the
drive and avoiding diskette whirring (which is caused by the calling of
routines which determine the filesystem and by the brain damaged hardware
which kludges disk changes of write protected drives). This sync operation
also cannot be interrupted by a context switch, so the update daemon is
run as a user process which makes a syscall.

[side note, from the above, you only need call MFS_SYNC once to sync all          
filesystems (on the first filesystem MFS_VERIFY returns the right magic
number). The preferred method though is sending anything other than
SIGSTOP and SIGKILL to the update process, this avoids whirring]
          
          This is not ideal, but the performance increase is so great that
I felt that some method compatible with the various older MiNT's out there
was more approprate than something which relied on a (possibly unofficial)
kernel patch. Besides, I leave the kernel alone unless I have no choice.
          If we want a single update process (or none at all) then I would
suggest either a new entry in the FILESYS structure (sync?) which is called
periodically, or some way of specifying an internal function to be called
at periodic intervals. The latter is perhaps preferable because it allows
more flexibility (you may not want all update processes to be called at
the same interval). I'd certainly support this if it ever became 'official'.
          Ah, one more thing, I can make the cache mode easily work on a
'per filesystem' basis, however I don't think it wise to make floppies
permanently not use turbo mode; the performance loss is considerable.

Regards and Seasons Greetings, Steve.