> >Description:
> 
> A portal filesystem mounted to /p prevents the root filesystem from being 
> fsck'd clean. Unmounting /p will fix this. Somehow this propagated semi-
> permanently, so fsck at boottime would barf (although /p isn't mounted then)
> and try to fix it. It confused me a bit, which resulted in the completely
> bogus kern/395 bug report.

I just looked into this, and i think i know why it happens.

This is caused by the perverse way that the portal user-land process
sets up its connection to the kernel-level portion of the file system.
To set up the connection between the user-land process and
the file system, it creates a unix-domain socket, bind it to a
pathname, then _unlink it_ from the file system.  It still has an
inode on disk however, because it is still open.

when you unmount the portal file system, that reference goes away,
and so the inode is reclaimed.  If you simply 'halt' the system,
the user-land process associated with the file system isn't stopped
cleanly, and therefore the reference to the inode is never released
properly (and so fsck discovers it and cleans it up).

I think that if you use 'shutdown' rather than 'halt' or 'reboot'
the portal daemon will be killed properly.

it's unclear what the 'perfect' fix for this is.  Probably it would
include fixing the way a portal FS talks to its daemon.


cgd

------------------------------------------------------------------------------