On Fri, 2007-08-31 at 01:07 -0700, Linus Torvalds wrote:
That would be a major change in existing semantics. The default has been
"sharecache" ever since Al Viro introduced the "sget()" function some 6
or 7 years ago. The problem was that we never advertised the fact that
the kernel was overriding your mount options, and so sysadmins were
(rightly IMO) complaining that they should _know_ when the client does
this.
The list of known problems with a "nosharecache" default is nasty too:
- file and directory attribute and data caching breaks.
Applications will see stale data in cases where they otherwise
would not expect it.
- the existing dcache and icache issues when a file is renamed
or deleted on the server are now extended to also include the
case where the rename or deletion occurs on an alias in another
directory on the client itself. In particular, sillyrename will
break.
- file locking breaks (the server knows that the client holds
locks on one file, whereas the client thinks it holds locks on
several).
- the NFSv4 delegation model breaks: the client will be using
OPEN when it could use cached opens. More importantly, when
performing an operation that requires it to return the
delegation on the aliased file, it won't know until the server
sends it a callback.
...and of course, the amount of unnecessary traffic to the server
increases. I'm not aware of any sane way of dealing with those issues,
and I doubt Solaris has a solution for them either.
Trond
-
