Subject: [nfsv4] READ_PLUS holes

From: Anna Schumaker <[email-masked]>
Date: Wed, 20 Nov 2013 15:14:39 -0500

Section 14.10.3 says "Both an ADH and a hole must be returned in its entirety - clients must be prepared to get more information than they requested.  Both the start and the end of the hole may exceed what was requested".

So let's say I have a file with the following layout:

 0 - 10: Data
11 - 20: Hole
21 - 30: Data

Now let's say my client requests a READ_PLUS starting at offset 15.  The spec says I should tell the client:

11 - 20: Hole
21 - 30: Data

On Linux, I can detect if I'm in a hole easily enough: if offset == lseek(offset, SEEK_HOLE) then offset already points to a hole.  Unfortunately, lseek doesn't have a concept for seeking to the beginning of a hole, so I'm forced to to seek over the entire file to find where this hole starts.  This sounds like potentially tedious code, and I think I should instead tell the client:

15 - 20: Hole
21 - 30: Data

Then 11 - 14 can be discovered on a future READ_PLUS call.

Thoughts?

Anna

---

From: Marc Eshel <[email-masked]>
Date: Wed, 20 Nov 2013 12:28:33 -0800

"nfsv4" <[email-masked]> wrote on 11/20/2013 12:14:39 PM:

> From: Anna Schumaker <[email-masked]>
> To: "nfs >> \"[email-masked]\"" <[email-masked]>, 
> Date: 11/20/2013 12:14 PM
> Subject: [nfsv4] READ_PLUS holes
> Sent by: "nfsv4" <[email-masked]>
> 
> Section 14.10.3 says "Both an ADH and a hole must be returned in its
> entirety - clients must be prepared to get more information than 
> they requested.  Both the start and the end of the hole may exceed 
> what was requested".
> 

I would just return 
15 - 20: Hole 
21 - 30: Data

I think it says that the server might return more information to the 
client but it doesn't have to.
Marc.

> 
> 11 - 20: Hole
> 21 - 30: Data
> 
> On Linux, I can detect if I'm in a hole easily enough: if offset == 
> lseek(offset, SEEK_HOLE) then offset already points to a hole. 
> Unfortunately, lseek doesn't have a concept for seeking to the 
> beginning of a hole, so I'm forced to to seek over the entire file 
> to find where this hole starts.  This sounds like potentially 
> tedious code, and I think I should instead tell the client:
> 
> 15 - 20: Hole
> 21 - 30: Data
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 20 Nov 2013 15:31:46 -0500

> On Linux, I can detect if I'm in a hole easily enough: if offset == lseek(offset, SEEK_HOLE) then offset already points to a hole.  Unfortunately, lseek doesn't have a concept for seeking to the be…

So you're trying to implement the server side of READ_PLUS using lseek?

Making that "must" a "may" would sound reasonable to me... something
like "an entire hole may be returned even if a client's request only
covered part of it".

--b.

---

From: Anna Schumaker <[email-masked]>
Date: Wed, 20 Nov 2013 15:33:36 -0500

> So you're trying to implement the server side of READ_PLUS using lseek?

It's the first way I thought of.

> like "an entire hole may be returned even if a client's request only

I like this wording better.

---

From: Marc Eshel <[email-masked]>
Date: Wed, 20 Nov 2013 12:55:10 -0800

That must should be changed in section 14.10.3 but in section 5.3.1 it 
doesn't say must just that it can. 

if a READ_PLUS occurs in the middle of a hole or ADH, the
   server can send back a range which starts before the offset and
   extends past the range.

From:   Anna Schumaker <[email-masked]>
To:     "J. Bruce Fields" <[email-masked]>, 
Cc:     "nfs >> \"[email-masked]\"" <[email-masked]>
Date:   11/20/2013 12:33 PM
Subject:        Re: [nfsv4] READ_PLUS holes
Sent by:        "nfsv4" <[email-masked]>

>> Section 14.10.3 says "Both an ADH and a hole must be returned in its 
entirety - clients must be prepared to get more information than they 
requested.  Both the start and the end of the hole may exceed what was 
requested".
lseek(offset, SEEK_HOLE) then offset already points to a hole. 
Unfortunately, lseek doesn't have a concept for seeking to the beginning 
of a hole, so I'm forced to to seek over the entire file to find where 
this hole starts.  This sounds like potentially tedious code, and I think