Albert Chin wrote: > We have a X4100 running b66 exporting ZFS filesystems via NFS to > several HP-UX clients. Due to bug 6538387, > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6538387,
Condolences that you haven't been able to upgrade to HP-UX 11.31 yet. As you know, that has the client side fix for the underlying problem. > we must mount the ZFS filesystems from our X4100 server as NFSv2. > However, this causes problems with getconf(1) on this system: > > hp-ux# mount -o vers=2 b66:/opt/tww /mnt > hp-ux# getconf NAME_MAX /mnt > getconf NAME_MAX /mnt: Operation not supported Right - NFSv2 doesn't have a PATHCONF op. On Solaris, we have a way to work around that with a different version of the MOUNT protocol which can transmit a static set of per-filesystem values. The client can then stash those and use it to answer questions. That would support NAME_MAX if HP supported MOUNTVERS_POSIX (== 2). You can see more on /usr/include/rpcsvc/mount.x on a Solaris system. > We can "zfs set xattr=off" on the ZFS filesystems as, according to > zfs(1m): > xattr=on | off > Controls whether extended attributes are enabled for > this file system. The default value is "on". Does this actually help you at all? If so, do you know why? I don't see a connection to extended attributes here. > However, this isn't enough. Is it possible to disable the extra > attribute bits used by NFS when NFSv3 is being used by the client? We > don't need any extra attribute bits more than the standard UNIX > permissions. The root cause of the bug you're fighting is that the HP client is programmed to use a "guard" - it echos a server-generated time and asks the server to make sure it's correct. The problem is that the HP-UX client is storing that value with only microsecond precision, so the fact that ZFS has nanosecond precision means the client's request doesn't match and needs to be rejected. This is referring to the sattrguard3 field for SETATTR in /usr/include/rpcsvc/nfs_prot.x if you want to have a look. With this kind of problem, the only two options are to change the way the client is coded or to make the server either throw away precision or accept a value that's actually incorrect. There's no server side workaround that I could recommend here; sorry about that :-( Rob T
