Subject: [nfsv4] keeping the client and server layouts in sync

From: Benny Halevy <[email-masked]>
Date: Mon, 10 Jul 2006 19:53:54 -0400

Here's a summary of our discussion so far for tomorrow's IETF discussion.

* We've agreed on the do-one-thing-at-a-time model for voluntary layout
returns, requiring LAYOUTGET's for the same file to be
resolved before proceeding to do the voluntary LAYOUTRETURN.

  - There's text about that already in the 4.1 draft. We may want

    to be more specific about what clients MUST do.

  - We also need to think on compound {RETURN, GET} RPCs which

    serialize unambiguously but may need special handling

    when in flight while a CB_RECALL is sent.

* Dave's proposal for CB_LAYOUTRECALL is:

  - synchronize only with LAYOUTGETs listed in the CB_SEQUENCE

  - server will not grant any subsequent LAYOUTGETs (those not

    in the CB_SEQUENCE) any region that overlaps that recalled.

  my additions and comments:

  - client needs to take into account any in-flight LAYOUTRETURNs

    that intersect with the recalled range.

  - any LAYOUTRETURN for a region outside the recalled range must be
    treated as voluntary and be serialized with in-flight GETs.
    - This may (but is not likely to) happen with object layouts as we
      do not allow returning a sub-range of a layout segment.

  - we probably need some text about multiple overlapping recalls since
    LAYOUTRETURNs may fall in several recalled range and the bookkeeping
    at the server and client should take this into account.
    What should the server do with regards to CB_SEQUENCE for LAYOUTGETs
    that were not seen in the first return but were seen since?
    If the second CB_RECALL mentions them then the client will wait for
    them as suggested, yet the server cannot grant any of them, so it has
    no choice but rejecting them.
    - Dave Noveck suggested this:

	I think we can make a rule that a server not do recalls
	of overlapping ranges of a file from the same client,
	since the server is in a position to know what is being
	recalled and not recall what is already recalled, because
	there is no added value in doing so, and because it makes
	things much less straightforward.

        - But what if the client just doesn't return all recalled layouts
          in a timely manner. How long should the server wait? What should
          it do when the client times out?

Benny

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