Re: [RFC][PATCH 20/20] honor r/w changes at do_remount() time

[Dave Hansen]

On Sun, 2006-06-18 at 19:36 +0100, Al Viro wrote:
> On Fri, Jun 16, 2006 at 04:12:28PM -0700, Dave Hansen wrote:
> > 
> > Originally from: Herbert Poetzl <herbert@xxxxxxxxxxxx>
> > 
> > This is the core of the read-only bind mount patch set.
> > 
> > Note that this does _not_ add a "ro" option directly to
> > the bind mount operation.  If you require such a mount,
> > you must first do the bind, then follow it up with a
> > 'mount -o remount,ro' operation.
> 
> Hrm...  So you want r/o status of vfsmount completely independent from
> that of superblock?  I.e. allow writable vfsmount over r/o filesystem?
> I realize that we have double checks, but...

I think it does make sense to keep them separate.  I think of the
superblock flag is really there to describe the state of the filesystem.
Are we even _able_ to write to this thing now?

The vfsmount flag, on the other hand, spells out the intentions of the
person who _did_ the mount.  Do I _want_ this to be writable?  

Let's say that we eliminate the superblock r/o flag.  There's a
filesystem with one regular vfsmount, one r/o bind vfsmount, and one r/w
bind vfsmount.  It encounters an error.  Not having a superblock flag,
we must go find each vfsmount and mark it r/o (this also enlarges the
window during which the f/s might be written).

Now, the administrator decides that the fs is OK, and remounts it r/w.
The vfsmounts should obviously regain their original permissions, any
other behavior is pretty screwy.  To accomplish this, we need both a
"current write state" and a "previous write state", which probably means
a new flag in the vfsmount.

So, we've fanned out this "current state" information from the
superblock, increased the window of fs damage, and added some complexity
when we do the transitions between the states.  I think I like the way
it is now. :)

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/