On Tue, Jul 14, 2009 at 06:33:27PM -0400, Erez Zadok wrote: > In message <20090714220515.GH27582@shell>, Valerie Aurora writes: > > 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.: > > > > > > 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." > > > > Yeah, it's just a promise, one that the NFS server shouldn't make if > > it can't implement it. The client's sole responsibility is to fail > > gracefully if the server breaks its promise. > [...] > > How would the client detect that the server broke the promise? The same way we detect other NFS server bugs - frequently by crashing the client, but in the best case hitting code like: fs/nfs/inode.c.: if (!fattr->nlink) { printk("NFS: Buggy server - nlink == 0!\n"); goto out_no_inode; } If the server happily mounts with the server_ro option, and then writes to the exported file system, it's buggy. Deal accordingly. -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
