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? In theory, your client may never know b/c it'll never send the server any state-changing ops (e.g., creat, write, unlink). One really ugly idea might be for the client to try and create a dummy .nfsXXXXXX file on the server, and if that succeds, or the error returned isn't EROFS, the client can guess that the server's misbhaving. Erez. -- 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
