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

From: "Matt W. Benjamin" <[email-masked]>
Date: Thu, 30 Sep 2010 12:06:30 -0400 (EDT)

Hi,

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

I had the impression that there could be valid pnfs implementations for which this might be an onerous requirement.  Is that not the case?

Matt

----- "Dean Hildebrand" <[email-masked]> wrote:

> Hello,
> 
> I uploaded a new version of our internet draft "Simple and Efficient
> Read Support for Sparse Files".
> 

-- 

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: Thomas Haynes <[email-masked]>
Date: Thu, 30 Sep 2010 11:44:06 -0500

> I had the impression that there could be valid pnfs implementations for which this might be an onerous requirement.  Is that not the case?

On the server or client side?

On the server side, it might have to contact the MDS to get the information
or the MDS might have already informed the DS about the holes in the
file. Yes, very implementation dependent.

On the client side, converting an offset to a DS via the layout should
be very straight forward.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 30 Sep 2010 13:55:34 -0400

> I had the impression that there could be valid pnfs implementations for which this might be an onerous requirement.  Is that not the case?

There's no real reason I can see that the server couldn't return an
earlier offset if it wanted to: e.g. if it knows that the file is
unallocated up to offset X, but doesn't know about offsets after that,
then it could return offset X, length 0.  It'd be up to the server to
make the tradeoff between the expense of returning a smaller hole vs.
querying other server nodes or recalling layouts.

I think the draft could avoid this kind of confusion by avoiding
referring to allocated/unallocated blocks, and instead just treating
READ4reshole as a simple optimization for transferring long sequences of
zeroes.

(Well, it would still make sense to mention block allocation as
background motivation.)

--b.

---

From: Dean Hildebrand <[email-masked]>
Date: Thu, 30 Sep 2010 11:30:04 -0700

> I had the impression that there could be valid pnfs implementations for which this might be an onerous requirement.  Is that not the case?
Yes, could be.  I have so far stayed away from any 'capitalized' words 
stating what clients/server should and shouldn't do.  So in this case, I 
was trying to imply that the server, if it has the correct information, 
should return it.  If it doesn't have this information, or its too 
onerous to get, can just return zero in the data_length field.  In this 
way, it still benefits from not having to send the data back over the 
wire, just the return code and READ4reshole struct.

I believe Benny is describing this in more detail in another email, 
which I'm about to read and address.
Dean
> Matt
>
> ----- "Dean Hildebrand"<[email-masked]>  wrote:
>
>> Hello,
>>

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 30 Sep 2010 13:34:13 -0500

On Sep 30, 2010, at 1:30 PM, Dean Hildebrand wrote:

> 
> I believe Benny is describing this in more detail in another email, which I'm about to read and address.

Was that private email?

I don't see anything in the wg alias...

---

From: Benny Halevy <[email-masked]>
Date: Thu, 30 Sep 2010 20:50:13 +0200

> I don't see anything in the wg alias...

damn, I think we have a long standing bug with the Panasas mail server
and the ietf list that rejects emails coming from it. :-(
I'll resend from a different mail address...

Benny