Date: Sun, 15 Oct 2006 17:26:20 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca To: fs@freebsd.org Cc: mohan_srinivasan@yahoo.com Subject: Re: lost dotdot caching pessimizes nfs especially Message-ID: <200610152126.RAA49191@snowhite.cis.uoguelph.ca>
next in thread | raw e-mail | index | archive | help
> 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?200610152126.RAA49191>