lost dotdot caching pessimizes nfs especially

rick at snowhite.cis.uoguelph.ca rick at snowhite.cis.uoguelph.ca
Sun Oct 15 14:26:23 PDT 2006

> 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 mailing list