Subject: [nfsv4] WRITE_PLUS Question

From: Bryan Schumaker <[email-masked]>
Date: Wed, 21 Aug 2013 09:25:20 -0400

Hi guys!

I'm looking at WRITE_PLUS now.  The end of section 14.7.3 says "If the client supports WRITE_PLUS and any arm of the discriminated union other than NFS4_CONTENT_DATA, it MUST support CB_OFFLOAD".  Why is the callback optional in the NFS4_CONTENT_DATA case?  My understanding is that the server could still do an async write, and without the callback the client won't know when it's done.

Thanks!
Bryan

---

From: Bryan Schumaker <[email-masked]>
Date: Wed, 21 Aug 2013 12:32:01 -0400

> I'm looking at WRITE_PLUS now.  The end of section 14.7.3 says "If the client supports WRITE_PLUS and any arm of the discriminated union other than NFS4_CONTENT_DATA, it MUST support CB_OFFLOAD".…

I re-read 14.7.3.1 and saw the "data MUST be written synchronously" line, so I guess that answers that question.

However, I now have a question about using di_allocated to punch holes.  This is supposed to be used by the client to tell the server to deallocate blocks.  fallocate() on Linux will do the block deallocation automatically (there is no flag to control this behavior that I've seen), so I'm wondering: what is the advantage of having the client tell the server how to handle this instead of letting the underlying filesystem decide?

Thanks again!
Bryan

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 21 Aug 2013 16:51:55 +0000

> However, I now have a question about using di_allocated to punch holes.  This is supposed to be used by the client to tell the server to deallocate blocks.  fallocate() on Linux will do the block d…

What if the server does not support space reservation and the client wants the zeroing of blocks and not the deletion of data?

But it is a hint, perhaps we can record it better as:

   If the
   wpa_hole.di_allocated is set to TRUE, then the blocks SHOULD be zeroed
   and if it is set to FALSE, then they SHOULD be deallocated.  All
   further reads to this region MUST return zeros until overwritten.
   The filehandle specified must be that of a regular file.

---

From: Bryan Schumaker <[email-masked]>
Date: Thu, 29 Aug 2013 16:56:39 -0400

Hi!

I have a question with how the server interprets wp_stable in the case of using WRITE_PLUS for hole punching.  Would setting to UNSTABLE4 disable the callback and cause a commit?  Does DATA_SYNC4 or FILE_SYNC4 enable the callback and change if a commit is required?

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 29 Aug 2013 17:37:33 -0400

> so I guess that answers that question.

The section you quoted got me confused. 

It also says "MUST follow the same semantics of COMMIT as does the WRITE operation"

I think this would more clear if, instead of "data MUST be written synchronously",
it said something like "a WRITE_PLUS of data MAY NOT result in an asynchronous
transaction of the sort described in section 14.7.3.4."
_______________

From: [email-masked] [[email-masked]] On Behalf Of Bryan Schumaker [[email-masked]]
Sent: Wednesday, August 21, 2013 12:32 PM
To: nfs >> "[email-masked]"
Subject: Re: [nfsv4] WRITE_PLUS Question

Thanks again!
Bryan

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 30 Aug 2013 15:06:14 +0000

Either way, what is the expected behaviour of WRITE PLUS with the UNSTABLE flag set? Does it imply that the operation may need to be replayed in the same way that we do for ordinary WRITE if the COMMIT returns a different cookie?

Cheers
  Trond

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Noveck, David
> Sent: Thursday, August 29, 2013 5:38 PM
> To: Schumaker, Bryan; nfs >> "[email-masked]"
> > I re-read 14.7.3.1 and saw the "data MUST be written synchronously"
> > line, so I guess that answers that question.
> 
> I think this would more clear if, instead of "data MUST be written
> synchronously", it said something like "a WRITE_PLUS of data MAY NOT
> result in an asynchronous transaction of the sort described in section
> 14.7.3.4."
> _______________
> 
> > I'm looking at WRITE_PLUS now.  The end of section 14.7.3 says "If the
> client supports WRITE_PLUS and any arm of the discriminated union other
> than NFS4_CONTENT_DATA, it MUST support CB_OFFLOAD".  Why is the
> callback optional in the NFS4_CONTENT_DATA case?  My understanding is
> that the server could still do an async write, and without the callback the
> client won't know when it's done.
> >
> 
> However, I now have a question about using di_allocated to punch holes.
> This is supposed to be used by the client to tell the server to deallocate
> blocks.  fallocate() on Linux will do the block deallocation automatically (there
> is no flag to control this behavior that I've seen), so I'm wondering: what is
> the advantage of having the client tell the server how to handle this instead
> of letting the underlying filesystem decide?
> 
> Thanks again!
> Bryan
> 
> > Thanks!
> > Bryan

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 30 Aug 2013 11:18:57 -0400

I interpreted  "MUST follow the same semantics of COMMIT as does the WRITE operation" as implying it does.

-----Original Message-----
From: Myklebust, Trond [mailto:[email-masked]] 
Sent: Friday, August 30, 2013 11:06 AM
To: Noveck, David; Schumaker, Bryan; nfs >> "[email-masked]"
Subject: RE: [nfsv4] WRITE_PLUS Question

Cheers
  Trond

> client supports WRITE_PLUS and any arm of the discriminated union 
> other than NFS4_CONTENT_DATA, it MUST support CB_OFFLOAD".  Why is the 
> that the server could still do an async write, and without the 
> callback the client won't know when it's done.
> >
> 
> This is supposed to be used by the client to tell the server to 
> deallocate blocks.  fallocate() on Linux will do the block 
> deallocation automatically (there is no flag to control this behavior 
> that I've seen), so I'm wondering: what is the advantage of having the 
> client tell the server how to handle this instead of letting the underlying filesystem decide?
> 
> Thanks again!
> Bryan
> 
> > Thanks!
> > Bryan