Re: [nfsv4] New version of sparse draft(draft-hildebrand-nfsv4-read-sparse-01.txt)

["Matt W. Benjamin" <[e-mail]>]

Hi Pranoop,

I noted myself that the next offset return requirement. was potentially onerous, for the reason you state.  However, the response from Dean and explicated by Bruce is that the DS was not meant to be obligated to return the next filled offset, merely to return the information it has.  (Yes, you've raised an interesting point about this.)

It still seems to me, offhand, just as problematic for a different subset of implementations to have a new requirement to propagate hole information (synchronously?) to the MDS, as to have the DSes collectively aware of it.  That is, is it not a potential advantage of pNFS, as currently specified, that the MDS need not have global hole information either?

Thanks,

Matt

----- "Pranoop Erasani" <[e-mail]> wrote:

> > Hi,
> > 
> > Just relative to pNFS, my immediate reaction was that a DS might
> have
> > the relevant file allocation information, and the MDS might not. 
> 
> DS might have relevant file allocation information on data on itself,
> 
> not on other DSs'. AFAIK, pNFS does not mandate that each DS know
> about other DSs' information. It's the MDS that has access to DS
> information.
> 
> Given the current proposal, as part of the READ response, the DS is
> supposed to
> send the offset where the hole ends and the actual data begins. If the
> hole ends
> on a different DS, how is that DS responding to READ supposed to know
> this.
> How does the data server get to compute the information? Are all DSs'
> conscious
> Of how data is organized on other DSs' or is it the duty of the MDS to
> own
> that information? This is where, I feel that the existing proposal
> puts onerous 
> requirements on the pNFS Data Servers.
> 
> > With
> > READZ (is that the current operation name?), this doesn't seem to
> > present a problem. 
> 
> The draft seems to addresses the problem by just mentioning that each
> DS needs
> to know other DS's information.

This was clarified in subsequent email, as I attempt to summarize above.

> 
>    receives.  In addition, when a data server is returning a
>    READ4reshole structure, it should still contain the offset and
> length
>    of the next allocated block in the file, even if that block is not
>    located on that particular data server.
> 
> However, that is not a requirement that pNFS puts on the data servers.
> Isn't it? Are
> we wading into a path of new requirements for pNFS data servers here?
> 
> If my suspicion is true, the spirit of this proposal would discourage
> pNFS servers
> from implementing the sparse hints.
> 
> > It would, I guess, perhaps also not present a
> > problem if clients could get a hole map from a DS, but I think
> that's
> > not what the prior email seemed to be describing?
> 
> Well.. I started with the fact that some vendors could consider that
> hole map
> could be metadata  and thus implied that MDS would be in a better
> position to
> serve that rather than individual data servers (especially, if the
> holes
> span data servers).
> 
> To address the pNFS specific concerns from my original e-mail, we need
> to answer:
> 
> 1). Who owns the hole information
> 2). Who sends the hole information
> 3). How efficiently, they can communicate hole information spanning
> pNFS server set
> 
-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. [phone]
fax. [phone]
cel. 734-216-5309