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; nfsv4@ietf.org
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" <bfields@fieldses.org> 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
> > nfsv4@ietf.org
> > 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. 734-761-4689
> fax. 734-769-8938
> cel. 734-216-5309
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4