Re: [MiNT] Questions about minixfs and mintne

[Martin-Eric Racine <q-funk@pp.fishpool.com>]

> > The result of the problem you describe, is that errors like orphaned
> > inodes won't be fixed, even though the filesystem check says it does.
> 
> Yes, because the partition isn't locked the MinixFS is active. And the 
> MinixFS load the inode and block bitmaps at initalization into the RAM 
> and hold this sectors resident. So the fsck can fix the bitmaps on disk 
> but they are overwritten later from the MinixFS.

I seem to recall that Linux (and probably other Unices) have several
stages of INIT processes and one of the first is a filesystem check,
then root (/root /bin /sbin /etc) is mounted, then after a couple more 
INIT levels, the other filesystem hirarchies are mounted.

I don't know if we really need this many INIT levels, but maybe
introducing an FSCK level that goes before everything else and
acts as a single-user would fix those "cannot sync or lock drive"?

Btw, one thing that _is_ fixed since Frank's MinixFS is that doing
an FSCK on other drives beyond the one where the root is mounted
doesn't result in "inode not written when drive locked" error that
we used to have.  I have my spare ST-157 as SCSI 1 and it used to
give me errors, but not anymore.

However, that new MinixFS often gives me errors after a 'grep'
on a whole directory (ie:  grep "string" *.c) and I dunno why.
Any idea?

----------------------------------------------------------------
  Martin-Eric Racine * http://www.pp.fishpool.com/~q-funk/M-E/
  The Atari TT030 Homepage * http://members.tripod.com/~TT030/
----------------------------------------------------------------