Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done before/after Reclaim_complete?

[David Noveck <[e-mail]>]

>
>
>
> The more I think about it, the more I think you are correct, at least
> by default.
>

Not fully correct.  Some of what I told you is wrong and will be corrected
in -04.    The current target for submission is 4/23 but it is likely I
canpull that forward by a week.   In any case, I hope the following
fragment will be helpful:

/*
 * Includes multiple types of operations:
 *
 *    - Non-reclaim operations valid independent of grace period status.
 *    - Reclaim operations only used during a grace period.
 *    - Reclaim operations only used during a special delegation recovery
 *      period.
 */

enum open_claim_type4 {

        CLAIM_NULL              = 0,    /* Non-reclaim operation, */
        CLAIM_PREVIOUS          = 1,    /* Reclaim operation -- grace
                                                               period only.
*/
        CLAIM_DELEGATE_CUR      = 2,    /* Non-reclaim operation. */
        CLAIM_DELEGATE_PREV     = 3,    /* Reclaim operation -- special

  delegation recovery period
                                                                      only.
*/
        /*
         * Beyond this point, all values are new to v4.1.
         */

       /*
         * Like CLAIM_NULL, but object identified
         * by the current filehandle.
         */
        CLAIM_FH                = 4,    /* Non-reclaim operation. */

        /*
         * Like CLAIM_DELEGATE_CUR, but object identified
         * by current filehandle.
         */
        CLAIM_DELEG_CUR_FH      = 5,    /* Non-reclaim operation. */

        /*
         * Like CLAIM_DELEGATE_PREV, but object identified
         * by current filehandle.
         */
        CLAIM_DELEG_PREV_FH     = 6     /* Reclaim operation -- special

  delgation recovery period

 only. */
};

Why?
> Because when a client crashes/reboots and there is dirty data in the
> RAM cache it gets
> tossed, so tossing dirty data in the non-volatile cache when it cannot
> safely
> write it back to the server would be consistent with what happens now.
>

Yes, but the idea is to do better than that, when it can be written safely.

>
> For the case where the server is in grace, the client can use
> Open/Claim_previous
> and then, if the reply indicates an immediate recall of the
> delegation, it can write the dirty data
> back to the server before doing a Delegreturn.
>

True but that is an unusual case.

>
> For the case where the server is not in grace and the
> Open/Claim_delegate_prev
> fails, I think there is another way that the client can safely write
> the dirty data back.
> - If the client keeps track of the server's value of the change
> attribute for the file
>   in non-volatile storage.
>   - The client can try an
> Open/Claim_null/Open_share_access_write/Open_share_deny_write
>      followed by a Getattr of change in the same compound.
>      - if this succeeds and the change attribute is the same as the
> stored one, then I think the client can
>

If the  Open/Claim_delegate_prev fails, it would be because the delegation
was revoked, in which
case, change attribute will be different.   Also, in that case, checking
change attribute and proceding
to write is not safe, since the attribute can change after the check.  You
need continuous posession
of the delegation which is why clain-delege-prev was created.

       safely write the dirty data back to the server using the open_stateid
>        - then close the open_stateid
>
> An option other than tossing the data would be to flag it and let a
> sysadmin/user decide if
> merging it back to the server's file makes sense. Ugly but doable when
> the dirty data is in
> client non-volatile storage.
>

He could decide but I'm not sure on what basis he could decide,
especially since telling
him all the relevant information could be a security hole a megaparsec
wide. :-(

>
> rick
>
> >
> > --
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > [e-mail]
> >
> >
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>