Subject: RE: [nfsv4] CB_RECALL_ANY proposal

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 16 Feb 2006 12:57:36 -0500

> If the intention is to allow future revisions to increase the number
of
> masks, would it not be better to make type_mask a full-blown bitmap?

Will do that.

> Given that pNFS layouts are likely to differ greatly in size depending
> on the layout type a given client has chosen to use, perhaps we might
> want to allow for something more fine-grained than TYPE_MASK_LAYOUT?

I've tried to accommodate that in the second pass.  Take a look.

> Say the server suddenly notices that it has underestimated the number
of
> resources it needs to free up. Is it immediately free to send a new
> CB_RECALL_ANY to any given client? If so, how should that client deal
> with any races between the 2 CB_RECALL_ANY callbacks?

We could add sequencing but I don't think it is worth it.  I will
address 
this issue in the next version.

> Note that there exists at least one case where the server is not free
to
> refuse to give out recallable objects: namely that of a reboot
recovery.
> However, one can easily imagine situations where the server comes up
> again with fewer memory resources than when it crashed. Is there
> anything we can do to allow servers to deal with this situation too?

I don't see what the protocol can do.  If you have a requirement that
you have to have resources to reclaim objects, including but not 
limited to recallable ones, it is up to the server implementation to 
make sure it has sufficient resources.  If it naively makes the maximum 
number of such objects some fucntion of available memory (e.g. a fixed 
percentage), then any reduction in memory over a reboot may result in 
being unable to honor reclaim requests.  Either it has to limit the 
set of reclaimable objects to the set that can always be reclaimed, 
given the minimum amount of memory needed to bring the system up, 
or it has to allocate sufficient memory for this purpose based on 
persistent recording of the reclaimable object high-water mark.  Or 
something like that.  With recallable objects it might try to get by 
immediately recalling each object to make space for others but that 
only helps with recallable and the biggest problem with must-be-able-
to-reclaim objects is likely to be with non-recallable ones. 

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Monday, February 13, 2006 12:11 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] CB_RECALL_ANY proposal

On Mon, 2006-02-13 at 10:39 -0500, Noveck, Dave wrote:
> This note proposes a generalization of CB_RECALL_ANY, which was first 
> proposed as part of the directory delegations draft.  This feature
> is useful for multiple types of recallable objects, probably including

> those that haven't yet been thought of, and it would be good if the
> version included in v4.1 accommodated all current possible uses as
> well as having a good chance of being adaptable to future uses.
> 
> The following text is based on Saadia's directory delegation draft.
> 
> New Callback Operation: CB_RECALL_ANY - Limit recallable objects
> 
> 
>    SYNOPSIS
>         N, type_mask -> {}
> 
>    ARGUMENT
>         struct CB_RECALLANYY4args {
>                 uint4          objects_to_keep;
>                 uint4          type_mask;
>         }
> 
>         const TYPE_MASK_RDATA_DLG = 0x0001;
>         const TYPE_MASK_WDATA_DLG = 0x0002;
>         const TYPE_MASK_DIR_DLG = 0x0004;
>         const TYPE_MASK_LAYOUT = 0x0008;

If the intention is to allow future revisions to increase the number of
masks, would it not be better to make type_mask a full-blown bitmap?

Given that pNFS layouts are likely to differ greatly in size depending
on the layout type a given client has chosen to use, perhaps we might
want to allow for something more fine-grained than TYPE_MASK_LAYOUT?

Say the server suddenly notices that it has underestimated the number of
resources it needs to free up. Is it immediately free to send a new
CB_RECALL_ANY to any given client? If so, how should that client deal
with any races between the 2 CB_RECALL_ANY callbacks?

Note that there exists at least one case where the server is not free to
refuse to give out recallable objects: namely that of a reboot recovery.
However, one can easily imagine situations where the server comes up
again with fewer memory resources than when it crashed. Is there
anything we can do to allow servers to deal with this situation too?

Cheers,
  Trond

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