Hi Jeff,
On 27/08/2009, at 6:23 AM, Jeff A. Smith wrote:
> I'm targeting this fix for build snv_124.
That's *fantastic* news, thanks!
> It's strange that this issue hasn't been reported before, because
> our NFS4 server has always (mis)behaved this way since NFS4 first
> arrived in the first S10 release. Each year we attend Connectathon
> and do interop testing with Linux NFS implementors (and we haven't
> heard of this before), so it makes me wonder if a recent Linux NFS
> client change might
> be exposing our misbehavior.
This particular bug has been known about for a few years (google tells
me about NFSv4 O_EXCL and corrupt mtime back to 204) and specific
reporting of linux/solaris interoperability problems at least 2 years,
but nobody probably thought to report it to Sun until recently. I
found this one when we root-caused our problem a couple of months ago
http://marc.info/?l=linux-nfs&m=118299922500147&w=2
I suspect the reason is that so many people just haven't moved to
NFSv4 still considering it *too difficult* (rubbish, but more
difficult than NFSv3).
With more people using Solaris and OpenSolaris with a ZFS backing
datastore they will be really wanting to use NFSv4 mirror-mounts,
which somewhat surprisingly are supported natively from linux clients
- at least the entire filesystem and all ZFS children show up with a
single NFSv4 mount. As this usage rises, especially in enterprise,
this type of bug will have more of a chance to be discovered.
cheers,
James
