Re: CVS commit: src/sys/kern

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 26 Sep 2008 05:22:16 +1000
    From:        matthew green <mrg%eterna.com.au@localhost>
    Message-ID:  <8668.1222370536%splode.eterna.com.au@localhost>

  | you'd think that would be the case, but lots of inode atime updates
  | will likely be floating around the system not synced.

First, no, unlikely - I don't think I said the system was idle, cvs
updates (as in cvsup of the repository, then "cvs up"), scanning pkgsrc
for any changes so distfiles can be fetched, processing lots of mail,
etc, all mean plenty of churn in the vnode cache.

And second, why would I care?   A ro mount pretty much means that atime
is a waste of space anyway, if after the remount some inodes still get
flushed, fine, if they don't because it is now ro, also fine, no-one
really cares one way or the other.   Aside from atime values not being
meaningful (which they weren't anyway) nothing else is going to be
affected by this.

  | i wonder if the ro->rw can abuse this path -- block new writes to the
  | fs and then do all the things unmount would do.

I was going to reply to a message from ad earlier that seemed to have the
same premise - that is, that there is, or might be, something that's
around actively trying to write on the filesys when the rw->ro change
happens.  If that's the case, then failing the remount is the right thing
to do (which isn't to say that I believe there are no bugs in that area
right now).  That is, the reason people want to switch to ro isn't because
we believe there's a rogue process making bogus changes and we want to
stop it in a hurry, but because we want to preserve a stable state.

My presumption in all of this is that there is nothing with any write access
on the filesystem at the time the rw->ro change happens - whatever changes
needed to be made have been made, all sync'd.  That needs to be verified.
Open-for-write files (incl mmaps) are easy to find, all that's left are
in progress file system ops (unlink, rename, ...) - they'll all have a
locked vnode somewhere, if there are none of those, then none of those ops
are happening, so (if the dirty blocks/inodes have been flushed), it should
all be safe.    All these checks happen after the RDONLY flag is set so
no new opens, or other changes can happen (nothing new can appear).  If
the checks eventually fail, then RDONLY can be unset again.

kre