Andy Lubel wrote: > I've got a real doozie.. We recently implemented a b89 as zfs/nfs/ > cifs server. The NFS client is HP-UX (11.23). > > What's happening is when our dba edits a file on the nfs mount with > vi, it will not save. > > I removed vi from the mix by doing 'touch /nfs/file1' then 'echo abc > > /nfs/file1' and it just sat there while the nfs servers cpu went up > to 50% (one full core).
Hi Andy, This sounds familiar: you may be hitting something I diagnosed last year. Run snoop and see if it loops like this: 10920 0.00013 141.240.193.235 -> 141.240.193.27 NFS C GETATTR3 FH=6614 10921 0.00007 141.240.193.27 -> 141.240.193.235 NFS R GETATTR3 OK 10922 0.00017 141.240.193.235 -> 141.240.193.27 NFS C SETATTR3 FH=6614 10923 0.00007 141.240.193.27 -> 141.240.193.235 NFS R SETATTR3 Update synch mismatch 10924 0.00017 141.240.193.235 -> 141.240.193.27 NFS C GETATTR3 FH=6614 10925 0.00023 141.240.193.27 -> 141.240.193.235 NFS R GETATTR3 OK 10926 0.00026 141.240.193.235 -> 141.240.193.27 NFS C SETATTR3 FH=6614 10927 0.00009 141.240.193.27 -> 141.240.193.235 NFS R SETATTR3 Update synch mismatch If you see this, you've hit what we filed as Sun bugid 6538387, "HP-UX automount NFS client hangs for ZFS filesystems". It's an HP-UX bug, fixed in HP-UX 11.31. The synopsis is that HP-UX gets bitten by the nanosecond resolution on ZFS. Part of the CREATE handshake is for the server to send the create time as a 'guard' against almost-simultaneous creates - the client has to send it back in the SETATTR to complete the file creation. HP-UX has only microsecond resolution in their VFS, and so the 'guard' value is not sent accurately and the server rejects it, lather rinse and repeat. The spec, RFC 1813, talks about this in section 3.3.2. You can use NFSv2 in the short term until you get that update. If you see something different, by all means send us a snoop. Rob T _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
