Re: Union mounts, NFS, and locking

Erez Zadok
2009-07-14T20:37:19Z

In message <20090714201940.GF27582@shell>, Valerie Aurora writes:
> On Tue, Jul 14, 2009 at 02:19:26PM -0400, Erez Zadok wrote:
> > In message <20090714174828.GE27582@shell>, Valerie Aurora writes:
[...]
> > IMHO it's not worth at this stage to try and solve that problem in an
> > end-to-end manner (client to server). For a unioning layer to have to worry
> > about every possible change in any of the layers below it, is no different
> > than for every possible network-filesystem client to be able to guarantee
> > that nothing ever changes on the server unexpectedly: they don't, so why
> > should you have to solve this problem now? Not that I don't think it's an
> > important problem---I just don't see why *you* should have to solve this and
> > not the network-filesystem community: whatever solution that can come up,
> > can be applicable to any unioning layer. In the mean time, do the best you
> > can (e.g., ESTALE, readonly superblocks, etc.).
>
> 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."

In dealing with Unionfs, I've already had to face some really annoying
cases related to this. For example, when the client mounts read-write, but
the server does *any* combination of these two:

1. export readonly or readwrite
2. the native f/s exported can be locally mounted r/o or r/w.

Turns out that servers in that case will return any of EROFS, EACESS, EPERM,
and even ESTALE. So this is annoying to have to detect: a true permission
error should be returned to the user in unionfs, but a readonly access
should result in a copyup. I don't believe this behavior was standardized
in v2/v3.

So, in retrospect, it would be *great* if I had a client-side mount option
that could guarantee that the server is exporting/mounting readonly. But I
feel that for such a client-side option to work, some sort of information
has to flow b/t the server and the client to validate this readonly
assertion.

> /etc/exports:
> /client_root_fs thin-client-*.local.domain(server_ro,no_root_squash)
>
> Trond, is this super-gross or totally reasonable? Seems like we add
> new NFS mount options at the drop of a hat.
>
> -VAL

Erez.