Union mounts, NFS, and locking

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

 



For now, the union mount developers are assuming that the bottom layer
of a union mount is read-only.  This avoids the directory
topology-related problems summarized in this thread:

http://lkml.org/lkml/2008/1/17/4

The problem is making a file system really really read-only and not
letting someone else come along and start sneakily modifying it
underneath us.  My superblock readonly users patch
(http://lkml.org/lkml/2009/7/13/243) fixes that for local file
systems, but I'm not sure how to handle NFS mounts as the bottom
layer.  The client can mount it read-only, but that puts no
restrictions on the server.  However, the kernel can already deal with
things unexpectedly moving/going away on an NFS mount - ESTALE - and
the dentry/inode/etc. won't suddenly disappear in the way they can
with local file systems.  Is this good enough for union mounts?  Or do
we need to get the NFS server to promise that the exported file system
is really really read-only too?

(Yes, this depends on the actual concrete union mount locking scheme,
but I'm more interested in whether it can or cannot be solved in
principle.)

-VAL
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux