On Jun 6, 2008, at 11:22 AM, Andy Lubel wrote: > That was it! > > hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3 > nearline.host -> hpux-is-old.com NFS R GETATTR3 OK > hpux-is-old.com -> nearline.host NFS C SETATTR3 FH=F6B3 > nearline.host -> hpux-is-old.com NFS R SETATTR3 Update synch mismatch > hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3 > nearline.host -> hpux-is-old.com NFS R GETATTR3 OK > hpux-is-old.com -> nearline.host NFS C SETATTR3 FH=F6B3 > nearline.host -> hpux-is-old.com NFS R SETATTR3 Update synch mismatch > hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3 > nearline.host -> hpux-is-old.com NFS R GETATTR3 OK > hpux-is-old.com -> nearline.host NFS C SETATTR3 FH=F6B3 > nearline.host -> hpux-is-old.com NFS R SETATTR3 Update synch mismatch > hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3 > > It is too bad our silly hardware only allows us to go to 11.23. > That's OK though, in a couple months we will be dumping this server > with new x4600's. > > Thanks for the help, > > -Andy > > > On Jun 5, 2008, at 6:19 PM, Robert Thurlow wrote: > >> 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.
Update: We tried nfs v2 and the speed was terrible but the gettattr/setattr issue was gone. So what I'm looking at doing now is to create a raw volume, format it with ufs, mount it locallly, then share it over nfs. Luckily we will only have to do it this way for a few months, I don't like the extra layer and the block device isn't as fast as we hoped (I get about 400MB/s on the zfs filesystem and 180MB/s using the ufs-formatted local disk.. I just sure hope I'm not breaking any rules by implementing this workaround that will come back to haunt me later. -Andy >> >> >> Rob T > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
