Re: disk busy on startup

[Roland McGrath]

Previously it worked out ok if the filesystem was opened writable and then
fsck came along and set it readonly in rc.  Now it gets EBUSY, which
suggests that either diskfs has been broken or that something actually has
some peropen with the O_WRITE mode on some disk file.  My concern with just
starting the filesystem in --readonly mode is that then whatever this
client is, it will now fail to get the kind of peropen it wanted and
presumably is either failing or falling back to an O_RDONLY peropen.  We
are not noticing anything failing, so I assume the latter.  But if that is
the case, then whatever it is might not function properly later on after
the filesystem has been switched back to writeable.

If you reproduce this condition on a subhurd then it is not too hard to
figure out what is going on.  Attach gdb to the boot filesystem of the
subhurd and set a bkpt on diskfs_set_readonly, then try the "fsysopts / -r"
again from the subhurd's singleuser shell (after rc has barf from fsck
failing to do it).

>From there, you can look at all the peropens (there shouldn't be too many)
and find out what node the peropen is on.  Then you can note its inode
number and use ls -i or find -inum or debugfs or whatnot to find what file
it is (or perhaps just know by dead reckoning on its dn_stat values).

Another tack is to find the task that has the peropen (really the protid
port pointing to it).  Do this by looking at the receive right of the
protid and using portinfo -t PID on each of the tasks in the subhurd and
seeing who has a send right that maps to that receive right.