atom feed12 messages in org.kernel.vger.linux-nfsUnion mounts, NFS, and locking
FromSent OnAttachments
Valerie AuroraJul 14, 2009 10:48 am 
Erez ZadokJul 14, 2009 11:19 am 
Valerie AuroraJul 14, 2009 1:19 pm 
Erez ZadokJul 14, 2009 1:36 pm 
Valerie AuroraJul 14, 2009 3:04 pm 
Erez ZadokJul 14, 2009 3:33 pm 
Trond MyklebustJul 14, 2009 3:55 pm 
Valerie AuroraJul 14, 2009 5:19 pm 
J. Bruce FieldsJul 15, 2009 10:27 am 
Erez ZadokJul 15, 2009 5:14 pm 
Valerie AuroraJul 16, 2009 10:24 am 
David P. QuigleyJul 16, 2009 2:22 pm 
Subject:Union mounts, NFS, and locking
From:Valerie Aurora (vaur@redhat.com)
Date:Jul 14, 2009 10:48:05 am
List:org.kernel.vger.linux-nfs

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