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

["Roy, Dipankar" <[e-mail]>]

Hi Pranoop,

Dean and myself were discussing these use cases in an offline thread.
We haven't reached any definite conclusions about these. Please note
that by "sparse map" in the following, I mean a structure showing
holey regions of a file, without the need to performing a READ to
get the same information.

1. It would be nice to have a mechanism where a client can get a sparse
map of a bunch of files together (similar to a READDIR), instead of
performing READ on each individual file.

2. A sparse map enables clients and servers to share the information
instead of each server and client performing READ multiple times to
get the same map. I believe this will be useful for server side RFC
implementation and peer to peer NFS.

3. Since we are considering the READ only performance here, it is
unclear whether a sparse map will be more efficient to figure out
holes for a read delegation.

4. If the client punches holes to a file, i.e, the write holes case
would it make sense to perform a READ of the same area to know if
that is a hole.

Thanks
Dipankar 

-----Original Message-----
From: Erasani, Pranoop
Sent: Sun 10/3/2010 11:57 PM
To: Roy, Dipankar; Matt W. Benjamin; J. Bruce Fields
Cc: Benny Halevy; [e-mail]
Subject: RE: [nfsv4] New version of sparsedraft(draft-hildebrand-nfsv4-read-sparse-01.txt)
 
Hi Dipankar,

Great.

You had mentioned other use cases in one of your private e-mails. Would you mind sending e-mail to the WG alias as well?

- Pranoop

> -----Original Message-----
> From: Roy, Dipankar
> Sent: Sunday, October 03, 2010 5:49 AM
> To: Erasani, Pranoop; Matt W. Benjamin; J. Bruce Fields
> Cc: Benny Halevy; [e-mail]
> Subject: RE: [nfsv4] New version of sparsedraft(draft-hildebrand-nfsv4-
> read-sparse-01.txt)
> 
> Hi Pranoop,
> 
> Thanks a lot for proposing this.
> 
> I think the NFS server side copy RFC implementation can definitely
> benefit from this.
> 
> Regards
> Dipankar
> 
> -----Original Message-----
> From: Erasani, Pranoop
> Sent: Sun 10/3/2010 12:44 PM
> To: Matt W. Benjamin; J. Bruce Fields
> Cc: Benny Halevy; [e-mail]
> Subject: Re: [nfsv4] New version of sparsedraft(draft-hildebrand-nfsv4-
> read-sparse-01.txt)
> 
> > 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.
> 
>    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
> 
> - Pranoop
> 
> > Thanks,
> >
> > Matt
> >
> > ----- "J. Bruce Fields" <[e-mail]> wrote:
> >
> > >
> > > A few questions about a map:
> > >
> > > 	- What is its lifetime?  Will it be a recallable object like a
> > > 	  layout, or does the client invalidate it normally whenever it
> > > 	  would invalidate its data cache?
> > > 	- Does requesting the block map break write delegations, or (on
> > > 	  servers that support atime) update the atime?
> > > 	- How does a request for a map they interact with mandatory
> > > 	  locks?
> > >
> > > --b.
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/nfsv4
> >
> > --
> >
> > 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
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4