Subject: Re: [nfsv4] Request for an additional recommended attribute

From: Mike Eisler <[email-masked]>
Date: Thu, 1 Nov 2007 19:12:51 -0700 (PDT)

Dave Noveck has tried to explain to me many times why Jason's proposal
says:

> If the client's maximum I/O time is
> greater than the server's default, then the client MUST use SETATTR
> to
> inform the server of its maximum_I/O time.

And I'm not getting it.

To me, if the server has a guarantee of 30 seconds to either
definitively fail to do, or succeed to do the I/O, then if
client wants 60 seconds, a 30 second guarantee is semantically
the same (stop the I/O after 30 seconds if not done; suspend for 30
more seconds, return FAIL).

I'll apparently have to accept that this yet another mystery
of how blocks work. :-)

Since it is specific to blocks, I instead propose 
that maximum I/O time concept be
part of the blocks layout specific part of the layout hint
attribute.

The layout hint attribute is write-only today and would remain
write-only under this proposal.

The client can issue SETATTR for layout hint. The client can
read back what the server will actually do via the blocks layout type
specific content in the results of LAYOUTGET. 

So no changes to NFSv4.1 needed.

Some might argue that given that blocks server MUST respect the
maximum I/O time in the layout hint attribute that the 
name "hint" is a misnomer and the attribute should be rename to
say "info". I'd rather not; too much editing work for me. 
The pNFS blocks draft can mandate that some components 
of the hint be obeyed by the server.

Still I'm worried that a directive by the client to server to
change a 30 second SLA to 60 seconds is something not all servers
are going to be able to do; I understand that many of these
storage devices are relatively simple devices. So I think the pNFS
blocks draft should offer fencing as an alternative to
accommodate such devices.

--- [email-masked] wrote:

> In describing how the pNFS block client will implement fencing, it
> became necessary to define the maximum time that an I/O can be
> outstanding.  The client needs to communicate its value to the pNFS
> server.  The most appropriate means of doing so seems to be to
> provide a
> per server R/W recommended attribute, which clients can write.
> 
>  
> 
> I propose updating section 5.6 "Recommended Attributes - Definitions"
> with the following
> 
>  
> 
> maximum_io_time  74 uint32    R/W   The default maximum time that a
> client
> 
>                                     I/O to a data server can be
> active.
> 
>                                     Clients may update this value.
> 
>  
> 
>  
> 
>  
> 
> This parameter is defined in the next version of the pNFS block
> layout
> spec as follows:
> 
>  
> 
> --
> 
> "maximum_io_time" is the maximum time it can take for a client I/O to
> the storage system to either complete or fail; this value is often 30
> seconds or 60 seconds, but may be longer in some environments. .  If
> the
> maximum client I/O time cannot be bounded, this timed lease mechanism
> MUST NOT be used.  The client can use GETATTR to query the server's
> default setting of "maximum_io_time".  The server must respond with
> the
> maximum I/O time in seconds.  If the client's maximum I/O time is
> greater than the server's default, then the client MUST use SETATTR
> to
> inform the server of its maximum_I/O time.
> 
> --
> 
>  
> 
> Are there comments on introducing this new attribute into the NFSv4
> minor version 1 spec?  Is this a valid means of communicating a
> client
> specific value to the server?
> 
>  
> 
> -Jason Glasgow
> 
>  
> 
>  
> 
> > _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: [email-masked]
Date: Fri, 2 Nov 2007 17:44:40 -0400

Mike,

I am happy to use the layout hint to communicate to the server.  I will
update the block spec accordingly.  I agree that "hint" is now a
misnomer, but I can live with that.

As to changing the SLA from 30 to 60 seconds, the block spec will be
updated to allow for two behaviors.  I'm working on the exact wording,
but it will be something like:

A server which implements fencing can accept any maximum timeout value
from a client, and then fence the storage immediately if the lease
expires.

A server which does not implement fencing and does not wish to change
the SLA, can return an error to the SETATTR operation.  When a client
receives the error NFS4ERR_INVAL in response to the SETATTR operation
for layout hints, the client MUST NOT use the LAYOUTGET operation.
After responding with NFS4ERR_INVAL to the SETATTR for layout hint, the
server MUST return an error to all subsequent LAYOUTGET operations from
that client.

I think this should address your concerns.

-Jason

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Thursday, November 01, 2007 10:13 PM
To: [email-masked]
Subject: Re: [nfsv4] Request for an additional recommended attribute

And I'm not getting it.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 6 Nov 2007 02:39:22 -0800 (PST)

Jason,

This all looks good.