Re: Union mounts, NFS, and locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux