Date: Sun, 15 Oct 2006 14:35:09 -0700 (PDT) From: Mohan Srinivasan <mohan_srinivasan@yahoo.com> To: rick@snowhite.cis.uoguelph.ca, fs@freebsd.org Cc: mohan_srinivasan@yahoo.com Subject: Re: lost dotdot caching pessimizes nfs especially Message-ID: <20061015213509.60929.qmail@web30813.mail.mud.yahoo.com> In-Reply-To: <200610152126.RAA49191@snowhite.cis.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
SunOS and Solaris have provided close-to-open consistency for a very long time (for at least 15 years now). Not having the NFS client enforce close-to-open consistency will break a heck of a lot of applications. Since the other NFS clients (that matter) Solaris and Linux support it, I would argue that not supporting cto consistency is not really an option. We can however provide a mount option "nocto" (like those clients do) that overrides the default for specific cases (read only mounts, single client mounts etc). mohan --- rick@snowhite.cis.uoguelph.ca wrote: > > The clearing of the attrcache on nfs_open() is a requirement for close-to-open > > consistency, and this change fixed bugs that we saw internally relating to > > close-to-open consistency. > > I thought I'd just throw out some comments w.r.t. close-to-open consistency. > The concept comes from the Andrew File System (before Transarc's AFS), where > the client read the entire file upon Open and wrote the entire file to the > server upon Close, if it was modified. Therefore, other clients that opened > the file after the Close were guaranteed to see the changes. > > To the best of my knowledge, no NFS RFC has even required this behaviour. > It became common practice to flush writes to a server upon Close, so that > errors like ENOSPC could be returned by close(2) and a process could be > confident that the file was successfully saved if it didn't get an error > return from any write(2) syscall nor the subsequent close(2). > > As a side effect of the above behaviour (not required by RFC, but common > practice), NFS clients provided "approximate close-to-open consistency". > The "approximate" came from the fact that another client wouldn't notice > that the file had been modified until its attribute cache had timed out, > a few seconds after the writing client had flushed its writes upon close. > > Somewhere along the way, some people seem to have decided that > close-to-open consistency is required of NFS clients. I think the Linux crowd > is in that camp? > > Since NFS doesn't have a cache coherency protocol (even for NFSv4, although > the caching rules are somewhat more explicit in RFC3530), it is always > a performance<->consistency tradeoff. > > So, I guess you guys will have to decide, rick > ps: I do believe software that expects strict close-to-open consistency > over NFS is not correct, because that is not a requirement of the RFCs. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061015213509.60929.qmail>