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

From: "Matt W. Benjamin" <[email-masked]>
Date: Sat, 2 Oct 2010 17:07:27 -0400 (EDT)

Hi,

Just relative to pNFS, my immediate reaction was that a DS might have the relevant file allocation information, and the MDS might not.  With READZ (is that the current operation name?), this doesn't seem to present a problem.  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?

Thanks,

Matt

----- "J. Bruce Fields" <[email-masked]> 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
> [email-masked]
> 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

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sun, 3 Oct 2010 00:14:08 -0700

> 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

---

From: "Roy, Dipankar" <[email-masked]>
Date: Sun, 3 Oct 2010 18:18:58 +0530

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; [email-masked]
Subject: Re: [nfsv4] New version of sparsedraft(draft-hildebrand-nfsv4-read-sparse-01.txt)

- Pranoop

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sun, 3 Oct 2010 11:27:46 -0700

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

> From: Roy, Dipankar
> Sent: Sunday, October 03, 2010 5:49 AM
> To: Erasani, Pranoop; Matt W. Benjamin; J. Bruce Fields
> Subject: RE: [nfsv4] New version of
sparsedraft(draft-hildebrand-nfsv4-
> read-sparse-01.txt)
> Subject: Re: [nfsv4] New version of
sparsedraft(draft-hildebrand-nfsv4-
> read-sparse-01.txt)
> that information? This is where, I feel that the existing proposal
puts
> onerous

---

From: "Roy, Dipankar" <[email-masked]>
Date: Mon, 4 Oct 2010 13:23:34 +0530

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; [email-masked]
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

> Subject: RE: [nfsv4] New version of sparsedraft(draft-hildebrand-nfsv4-
> read-sparse-01.txt)
> 
> Hi Pranoop,
>