headers
Rick Macklem | 1 Feb 2012 01:13
Picon
Favicon

Re: Need for clarification of CLAIM_DELEGATE_PREV

This text reads well to me, except for a couple of trivial typos
that I've flagged below, rick.

----- Original Message -----
> So here is my updated proposal for clarification/corrections that
> I'd like the group to consider. The T* notes correspond to Trond's
> Comments.
> 
> ..> Explicitly state DELEGPURGE supported iff CLAIM_DELEGATE_PREV is
> T2> supported. Either both will return NFS4ERR_NOTSUPP or neither
> will.
> T2> Note that NFS4ERR_NOTSUPP is already used to indicate that
> exclusive
> T2> OPEN is not supported even though OPEN as a whole is.
> ..>
> T1> CLAIM_DELEGATE_PREV may only be used after a SETCLIENTID_CONFIRM
> and before
> T1> DELEGPURGE. When it is used outside of this context, the server,
> T1> if it supports CLAIM_DELEGATE_PREV, will return the error
> T1> NFS4ERR_INVAL
> ..> CLAIM_DELEGATE_PREV is primarily to deal with the case in which
> the
> ..> client (only) restarts.
> T1> Another case in which the client may use CLAIM_DELEGATE_PREV is
> T1> after receiving NFS4ERR_EXPIRED indicating a network partition
> T1> which resulted in loss of lease state. In such a situation, a
> T1> server MAY honor a CLAIM_DELEGATE_PREV reclaim, even though it
> T1> is not supporting "courtesy locks".
> ..>
> T5> One good way to think about persistent delegations is that for the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick Macklem | 1 Feb 2012 01:23
Picon
Favicon

Re: Need for clarification of CLAIM_DELEGATE_PREV

Trond Myklebust wrote:
> The text looks good to me, but I have a few more questions.
> 
> 1) In NFSv4 minor version 0, should we perhaps recommend that all
> clients issue DELEGPURGE after they have finished state recovery (i.e.
> make doing so a SHOULD). It seems that doing so can considerably
> reduce
> the resource burden on the server.
> 
> 2) Is CLAIM_DELEGATE_PREV allowed during the grace period? Both Rick
> and
> I seem to assume that it must be if the server is to support reclaims
> after a power failure, etc.
> If so, why could we not just let RECLAIM_COMPLETE act as an
> implicit DELEGPURGE and just deprecate the latter altogether?

Don't we want to keep DELEGPURGE so that a client can use it to
get the "hint" as to whether or not CLAIM_DELEGATE_PREV is supported?

Also, it might be less confusing if DELEGPURGE is retained with the
same semantics for all NFSv.n? It is only one extra Op, which could
be put in the same compound as RECLAIM_COMPLETE after recovery, I think?

> Are there any existing client implementations out there that
> would suffer if we did this?
> 
Not at this point for the FreeBSD one. I haven't gotten to the point
of doing CLAIM_DELEGATE_PREV yet, rick

_______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Myklebust, Trond | 1 Feb 2012 01:43
Picon

Re: Need for clarification of CLAIM_DELEGATE_PREV

On Tue, 2012-01-31 at 19:23 -0500, Rick Macklem wrote:
> Trond Myklebust wrote:
> > The text looks good to me, but I have a few more questions.
> > 
> > 1) In NFSv4 minor version 0, should we perhaps recommend that all
> > clients issue DELEGPURGE after they have finished state recovery (i.e.
> > make doing so a SHOULD). It seems that doing so can considerably
> > reduce
> > the resource burden on the server.
> > 
> > 2) Is CLAIM_DELEGATE_PREV allowed during the grace period? Both Rick
> > and
> > I seem to assume that it must be if the server is to support reclaims
> > after a power failure, etc.
> > If so, why could we not just let RECLAIM_COMPLETE act as an
> > implicit DELEGPURGE and just deprecate the latter altogether?
> 
> Don't we want to keep DELEGPURGE so that a client can use it to
> get the "hint" as to whether or not CLAIM_DELEGATE_PREV is supported?

If it needs that information, can't it just try to
OPEN(CLAIM_DELEGATE_PREV) on the file that it wants to cache?

According to Dave's proposed text, the server will return
NFS4ERR_NOT_SUPP in the case where there is no support at all, or
something along the lines of NFS4ERR_RECLAIM_BAD if there is support but
the delegation is being reclaimed at the wrong moment.

> Also, it might be less confusing if DELEGPURGE is retained with the
> same semantics for all NFSv.n? It is only one extra Op, which could
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Macklem | 1 Feb 2012 01:45
Picon
Favicon

Re: Volatile file handles

Bill Baker wrote:
> On 01/31/12 12:29, Haynes, Tom wrote:
> > Has anyone tried implementing volatile file handles in NFSv4?
> >
> > I know neither the Linux nor Solaris clients currently have it in
> > there.
> 
> The solaris client does support volatile file handles.
> 
Can I assume by support you mean that, when the client receives a
NFS4ERR_FHEXPIRED it does something like:
PUTROOTFH, LOOKUP,...,LOOKUP, GETFH
(for all the name components that were used to acquire the original FH)
and then it "hopes" that the new FH actually refers to the same file
object and not just a different one under the same name?

I can imagine some pretty interesting behaviour when the file object
has been replaced by one with the same name.

The FreeBSD server never generates them and the FreeBSD client has no
idea what to do with NFS4ERR_FHEXPIRED (ie. it's a fatal error).

rick, who is basically in Trond's camp on this one.

> >
> > In a round about way, if no one implements part of the spec, should
> > we
> > consider dropping support?
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Macklem | 1 Feb 2012 02:28
Picon
Favicon

Re: Need for clarification of CLAIM_DELEGATE_PREV

Trond Myklebust wrote:
> On Tue, 2012-01-31 at 19:23 -0500, Rick Macklem wrote:
> > Trond Myklebust wrote:
> > > The text looks good to me, but I have a few more questions.
> > >
> > > 1) In NFSv4 minor version 0, should we perhaps recommend that all
> > > clients issue DELEGPURGE after they have finished state recovery
> > > (i.e.
> > > make doing so a SHOULD). It seems that doing so can considerably
> > > reduce
> > > the resource burden on the server.
> > >
> > > 2) Is CLAIM_DELEGATE_PREV allowed during the grace period? Both
> > > Rick
> > > and
> > > I seem to assume that it must be if the server is to support
> > > reclaims
> > > after a power failure, etc.
> > > If so, why could we not just let RECLAIM_COMPLETE act as an
> > > implicit DELEGPURGE and just deprecate the latter altogether?
> >
> > Don't we want to keep DELEGPURGE so that a client can use it to
> > get the "hint" as to whether or not CLAIM_DELEGATE_PREV is
> > supported?
> 
> If it needs that information, can't it just try to
> OPEN(CLAIM_DELEGATE_PREV) on the file that it wants to cache?
> 
It could, but an OPEN is a lot more complicated to do than DELEGPURGE.
I'd just like to do this right at mount time to set a flag on the
(Continue reading)

Permalink | Reply | 0 comments |
headers
david.noveck | 1 Feb 2012 03:04

Re: Need for clarification of CLAIM_DELEGATE_PREV


> 1) In NFSv4 minor version 0, should we perhaps recommend that all
> clients issue DELEGPURGE after they have finished state recovery (i.e.
> make doing so a SHOULD). It seems that doing so can considerably reduce
> the resource burden on the server.

Here are the cases we've talked about:

     client reboot : has some CLAIM_DELEGATE_PREV and then DELEGPURGE,
                     but no state recovery.
     Server reboot : has state recovery including CLAIM_PREVIOUS reclaim of
                     delegation, and no DELEGPURGE.  Should there be a DELEGPURGE 
                     and why?
     Both reboot: has some CLAIM_DELEGATE_PREV which you can construe as state
                  recovery and a DELEGPURGE.
     Network partition with EXPIRED: may have some CLAIM_DELEGATE_PREV and
                                     A DELEGPURGE.  You may re-establish locks
                                     but not by doing reclaims but rather redoing
                                     opens/locks if it lets you. 

I think DELEGPURGE should stay associated with CLAIM_DELEGATE_PREV reclaims only.

I think that for the cases in which you can do CLAIM_DELEGATE_PREV, one SHOULD 
do a DELEGPURGE. 

> 2) Is CLAIM_DELEGATE_PREV allowed during the grace period? Both Rick and
> I seem to assume that it must be if the server is to support reclaims
> after a power failure, etc.

I've been assuming that as well but I agree it should be mentioned.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Shepler | 1 Feb 2012 04:04
Picon
Favicon

Re: Volatile file handles


> -----Original Message-----
> From: nfsv4-bounces <at> ietf.org [mailto:nfsv4-bounces <at> ietf.org] On Behalf Of
> Rick Macklem
> Sent: Tuesday, January 31, 2012 4:45 PM
> To: Bill Baker
> Cc: nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] Volatile file handles
> 
> Bill Baker wrote:
> > On 01/31/12 12:29, Haynes, Tom wrote:
> > > Has anyone tried implementing volatile file handles in NFSv4?
> > >
> > > I know neither the Linux nor Solaris clients currently have it in
> > > there.
> >
> > The solaris client does support volatile file handles.
> >
> Can I assume by support you mean that, when the client receives a
> NFS4ERR_FHEXPIRED it does something like:
> PUTROOTFH, LOOKUP,...,LOOKUP, GETFH
> (for all the name components that were used to acquire the original FH)
> and then it "hopes" that the new FH actually refers to the same file
> object and not just a different one under the same name?
> 
> I can imagine some pretty interesting behaviour when the file object has
> been replaced by one with the same name.
> 
> The FreeBSD server never generates them and the FreeBSD client has no idea
> what to do with NFS4ERR_FHEXPIRED (ie. it's a fatal error).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vitaliy Gusev | 1 Feb 2012 10:15
Favicon

Question about OpenOwner table overflow

Hello!

During reading rfc3530 and rfc5661 I didn't find any mentions about 
nfs-server behaviour if client has forgotten about opened file (client 
alive and sends RENEW on time).

So openowner, stateid-s entries on server can grow endlessly.

Am I missing something?

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 17 comments |
headers
Myklebust, Trond | 1 Feb 2012 14:35
Picon

Re: Question about OpenOwner table overflow

On Wed, 2012-02-01 at 13:15 +0400, Vitaliy Gusev wrote:
> Hello!
> 
> 
> During reading rfc3530 and rfc5661 I didn't find any mentions about 
> nfs-server behaviour if client has forgotten about opened file (client 
> alive and sends RENEW on time).
> 
> So openowner, stateid-s entries on server can grow endlessly.
> 
> Am I missing something?

This is why OPEN is allowed to return NFS4ERR_RESOURCE which, in this
instance, is the equivalent of returning the POSIX error "EMFILE". It is
up to the server to determine how many simultaneous open files it will
allow the client, and to enforce that limit once it is hit.

Cheers
  Trond

--

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust <at> netapp.com
www.netapp.com

_______________________________________________
nfsv4 mailing list
(Continue reading)

Permalink | Reply | 16 comments |
headers
Vitaliy Gusev | 1 Feb 2012 15:07
Favicon

Re: Question about OpenOwner table overflow

On 02/01/2012 05:35 PM, Myklebust, Trond wrote:
> This is why OPEN is allowed to return NFS4ERR_RESOURCE which, in this
> instance, is the equivalent of returning the POSIX error "EMFILE". It is
> up to the server to determine how many simultaneous open files it will
> allow the client, and to enforce that limit once it is hit.

Ok. One client can open/forgot 1000 files. 1000 clients can open/forgot 
1M files. It looks like good way for DOS attack.

Why do not require to update a OPEN in lease time.

---
Vitaliy Gusev

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 15 comments |

Gmane