Re: Union mounts, NFS, and locking

Valerie Aurora
2009-07-15T00:19:33Z

On Tue, Jul 14, 2009 at 06:33:27PM -0400, Erez Zadok wrote:
> In message <20090714220515.GH27582@shell>, Valerie Aurora writes:
> > On Tue, Jul 14, 2009 at 04:36:40PM -0400, Erez Zadok wrote:
> > > In message <20090714201940.GF27582@shell>, Valerie Aurora writes:
> > >
> > > > Okay, so my best idea for a solution is to introduce a new NFS mount
> > > > option that means the server promises that the exported file system is
> > > > read-only (using superblock read-only count scheme locally). E.g.:
> > >
> > > How would the server be able to guarantee that? Are you planning to change
> > > the protocol or implementation somehow? Are you assuming that the server
> > > will be running linux w/ special r/o sb support? If so, it won't work on
> > > other platforms (NFS is supposed to be interoperable in principle :-)
> > >
> > > Without a protocol change, such an option (if I understood you), is at best
> > > a server promise to "behave nice."
> >
> > Yeah, it's just a promise, one that the NFS server shouldn't make if
> > it can't implement it. The client's sole responsibility is to fail
> > gracefully if the server breaks its promise.
> [...]
>
> How would the client detect that the server broke the promise?

The same way we detect other NFS server bugs - frequently by crashing
the client, but in the best case hitting code like:

fs/nfs/inode.c.:

if (!fattr->nlink) {
printk("NFS: Buggy server - nlink == 0!\n");
goto out_no_inode;
}

If the server happily mounts with the server_ro option, and then
writes to the exported file system, it's buggy. Deal accordingly.

-VAL