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

["Erasani, Pranoop" <[e-mail]>]

> -----Original Message-----
> From: Matt W. Benjamin [mailto:[e-mail]]
> Sent: Sunday, October 03, 2010 8:20 AM
> To: Erasani, Pranoop
> Cc: Benny Halevy; [e-mail]; J. Bruce Fields
> Subject: Re: [nfsv4] New version of sparse draft(draft-hildebrand-
> nfsv4-read-sparse-01.txt)
> 
> 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.)

Yup, if pNFS data servers are not obliged to return this, there is not
much value w.r.t pNFS.

> 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?

I totally agree. I was not requiring that all MDSs' have information
about all DSs' holes. My wording initially may gave given some
hint as to this requirement, but the intent was not to require. But, to
state that our server could potentially have the information.

But, in general, an MDS is more likely to have information about DS than
a DS about another DS.

- Pranoop

> 
> 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