Subject: Re: [nfsv4] v4.2 write_response4 wr_count

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 9 Apr 2014 06:01:46 +0000

So, length4 while it looks correct, it may not be correct:

typedef :uint64_t:length4:Describes LOCK lengths.

Ahh, looks like someone changed that definition in 5661:

typedef length4 threshold4_read_size;
typedef length4 threshold4_write_size;
typedef length4 threshold4_read_iosize;
typedef length4 threshold4_write_iosize;

If we allow the hole punch to be a length4, then that means we are effectively
allowing 64 bit large writes. And as Anna points out, that means we need to
in turn allow for a 64-bit wr_count in the response.

Which would mean we would need to specify that the upper 32 bits MUST
be zero if the arm was NFS4_CONTENT_DATA.

But it also has an impact with READ_PLUS. If the request is a 32 bit
rpa_count and we encounter a hole, one of two things may occur:

A) The server sends back a hole with a 64 bit di_length. This is completely
valid as the server can return the entire hole.

B) The server decides to send back zero'ed data in the NFS4_CONTENT_DATA
arm. Why? No clue. But it can only send back rpa_count in d_data. Which
means the client would have to keep on reading until it hit the end of the
hole. So a braindead server.

A 64-bit wr_count is future-proof if we add 64 bit I/O.

On Mar 17, 2014, at 8:53 PM, Marc Eshel <[email-masked]<mailto:[email-masked]>> wrote:

Yes, I agree wr_count should be 64-bit.
Marc.

From:        Anna Schumaker <[email-masked]<mailto:[email-masked]>>
To:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
Date:        03/17/2014 09:37 AM
Subject:        [nfsv4] v4.2 write_response4 wr_count
Sent by:        "nfsv4" <[email-masked]<mailto:[email-masked]>>
________________________________

Hi,

The wr_count field of a write_response4 is defined as a 32-bit count4, but hole punching allows for a 64-bit length.  Should wr_count be a length4 instead?

Anna

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

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

---

From: Marc Eshel <[email-masked]>
Date: Wed, 9 Apr 2014 12:41:21 -0700

So are you going to change it to 64 bits? I don't see the problem with a 
field that is bigger than what we might support in read or write size.
Marc.

From:   "Haynes, Tom" <[email-masked]>
To:     Marc Eshel/Almaden/IBM@IBMUS, 
Cc:     "Schumaker, Anna" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:   04/08/2014 11:01 PM
Subject:        Re: [nfsv4] v4.2 write_response4 wr_count

If we allow the hole punch to be a length4, then that means we are 
effectively
allowing 64 bit large writes. And as Anna points out, that means we need 
to
in turn allow for a 64-bit wr_count in the response.

A) The server sends back a hole with a 64 bit di_length. This is 
completely
valid as the server can return the entire hole.

On Mar 17, 2014, at 8:53 PM, Marc Eshel <[email-masked]> wrote:

From:        Anna Schumaker <[email-masked]> 
To:        "[email-masked]" <[email-masked]>, 
Date:        03/17/2014 09:37 AM 
Subject:        [nfsv4] v4.2 write_response4 wr_count 
Sent by:        "nfsv4" <[email-masked]> 

Hi,

The wr_count field of a write_response4 is defined as a 32-bit count4, but 
hole punching allows for a 64-bit length.  Should wr_count be a length4 
instead?

Anna

[email-masked]

[email-masked]

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 9 Apr 2014 20:33:04 +0000

I thought the last line stated that future proofing was a good reason to do it. If we didn't we would have an issue going to large writes in a future minor version.

On Apr 9, 2014, at 12:41 PM, "Marc Eshel" <[email-masked]<mailto:[email-masked]>> wrote:

So are you going to change it to 64 bits? I don't see the problem with a field that is bigger than what we might support in read or write size.
Marc.

From:        "Haynes, Tom" <[email-masked]<mailto:[email-masked]>>
To:        Marc Eshel/Almaden/IBM@IBMUS,
Cc:        "Schumaker, Anna" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        04/08/2014 11:01 PM
Subject:        Re: [nfsv4] v4.2 write_response4 wr_count
________________________________

Hi,

Anna

---

From: Christoph Hellwig <[email-masked]>
Date: Thu, 10 Apr 2014 13:31:06 +0200

> I thought the last line stated that future proofing was a good reason to do it. If we didn't we would have an issue going to large writes in a future minor version.

I think the right fix is to drop the data arm of WRITE_PLUS while making the
count 64-bit.  Right now the data arm doesn't buy anything over a real write.
So far it seemed like it was a useless but also harmless addition, but if it
also needs special language to forbird certain larger results I don't think
it's worth adding at all.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 10 Apr 2014 08:06:42 -0700

> it's worth adding at all.

+1

I was thinking about this myself. We need a READ_PLUS in order to get holes
back when we might expect data. But for the WRITEs, the client damn well knows
if it is sending data or a hole.

I'll push a new version of the draft out this week. It will have the following changes:

1) Split WRITE_PLUS into:
a) WRITE for data
b) WRITE_HOLE for holes
c) WRITE_SAME for ADHs.

2) Make the whr_count 64 bit for holes in the WRITE_HOLE response.

3) Add a new section about 4.1 compatibility explicitly stating that:
a) stateids have not changed 
b) layouts have not changed

and that the approach used by the server to generate them in NFSv4.1
is perfectly valid for NFSv4.2.

I.e., unlike the move from NFSv4.0 to NFSv4.1, there is no semantic
difference in stateids going from NFSv4.1 to NFSv4.2.

---

From: Anna Schumaker <[email-masked]>
Date: Thu, 10 Apr 2014 11:29:07 -0400

> 2) Make the whr_count 64 bit for holes in the WRITE_HOLE response.

Thanks, Tom!  I'll let you know about bugs in the new draft as I find them =)

Anna