On Wed, Jul 15, 2009 at 01:27:59PM -0400, J. Bruce Fields wrote: > On Tue, Jul 14, 2009 at 06:05:16PM -0400, Valerie Aurora wrote: > > 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.: > > Language nitpick: the term "read-only" is confusing. Files > (/proc/mounts) and filesystems (nfs) that are "read-only" can still > change. > > I'd be happier with "unchanging" or "constant" or "static". What about "immutable"? It should be familiar from inode attributes. > The mount options aren't really in the protocol--so it'd probably take > the form of a filesystem-granularity attribute that the client could > query (and then fail the mount if the client didn't like the answer). > > But even then: the fact is that someone will want to update the > filesystem some day. And there's no way to force every client > administrator to remount. So we'd have to decide how to handle that > case. Agreed. I'm no NFS expert, but I think that treating it as if the NFS server had stopped responding might be a start? -VAL -- 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
