zfs discuss - Aug 2007 - ZFS Time

I have a customer who is running into bug 6538387.  This is a problem  
with HP-UX clients accessing NFS mounts which are on a ZFS file  
system.  This has to do with ZFS using nanosecond times and the HP  
client does not use this amount of precision.  This is not an issue  
with ufs as it does not support this precision either.

Does anyone know what this extra precision in time does for ZFS?  The  
sales group thinks that there should be an option to turn this off.    
Although I believe that it probably adds to ZFS''s capabilities.

I understand that this is an HP issue that is fixed at a later  
version of HP-UX.  If anyone has some insight on why the more precise  
time it would be greatly appreciated.

Robert Olinski <Robert.Olinski at Sun.COM> wrote:
> I have a customer who is running into bug 6538387.  This is a problem  
> with HP-UX clients accessing NFS mounts which are on a ZFS file  
> system.  This has to do with ZFS using nanosecond times and the HP  
> client does not use this amount of precision.  This is not an issue  
> with ufs as it does not support this precision either.
UFS uses fine grained time stams since ~ 20 years. I see no difference to ZFS.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Robert Olinski wrote:
> I have a customer who is running into bug 6538387.  This is a problem  
> with HP-UX clients accessing NFS mounts which are on a ZFS file  
> system.  This has to do with ZFS using nanosecond times and the HP  
> client does not use this amount of precision.  This is not an issue  
> with ufs as it does not support this precision either.
I investigated this bug, and there''s tracks on the nfs-discuss alias.
Here''s a summary of the situation.

The HP client is programmed to use a "guard" on the SETATTR operation;
it echos a server-generated timestamp and asks the server to make sure
it''s correct.  The purpose of this is to make sure the client has the
correct file, not one another client may have created.

The root cause of 6538387 is that the HP-UX client is storing that
timestamp value with only microsecond precision, so the fact that ZFS
has nanosecond precision means the client''s request doesn''t
match.
Per RFC 1813, the SETATTR op needs to fail.  This is referring to the
sattrguard3 field for SETATTR in /usr/include/rpcsvc/nfs_prot.x
if you want to have a look.  The fix available in HP-UX 11.31 could
expand their attribute cache to handle full precision, or it could
simply retry by doing a GETATTR and keeping the encoded value around
for that.

 > Does anyone know what this extra precision in time does for ZFS?  The
 > sales group thinks that there should be an option to turn this off.

ZFS stores file timestamps (struct timespec), with nanosecond precision.
Since the on-disk format was new and didn''t have arbitrary limits, and
since the system has that precision available, it would take more code
to throw precision away than to keep it.  As systems get faster, the
precision will find uses.

With this kind of problem, the proper fix is to change the client.
To change it on the server, we would need to either dumb-down ZFS to
throw away precision, or hack the NFS server to accept a value that''s
illegal per the RFC.  With HP-UX 11.31 available, I would not support
changing Solaris ZFS or NFS to address this.

Rob T