lost dotdot caching pessimizes nfs especially
mohan_srinivasan at yahoo.com
Sun Oct 15 14:35:14 PDT 2006
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).
--- rick at 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.
More information about the freebsd-fs