(Haven't I already written an answer to this? Anyway, I cannot find it.)
Nils Goroll <[EMAIL PROTECTED]> writes:
>> In a snoop I see that, when the access(2) fails, the nfsclient gets
>> a "Stale NFS file handle" response, which gets translated to an
>> ENOENT.
>
> What happens if you use the noac NFS mount option on the client?
No change. (I'll skip your other questions, because:)
In between a colleague of mine has found the apparent root cause of
the problem. The zfs man page reads, under "zfs receive":
If an incremental stream is received, then the
destination file system must already exist, and its most
recent snapshot must match the incremental stream's
source. The destination file system is unmounted and
cannot be accessed during the receive operation.
I still think there might be an NFS issue involved, as in my
understanding a temporary unmount should not affect the NFS mount
much, if a server reboot doesn't. But the exported file system being
unmounted in between makes this behaviour much more plausible and
leaves us with little hope that this might be resolved very soon.
Mounting the file system directly from the primary source is a
feasible workaround, so that problem is not an issue for me any more
at the moment. Of course, thanks for your help anyway!
Regards, Juergen.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
