Subject: Re: [nfsv4] FILE_SYNC4 to the DS (Errata ID: 2751)

From: "Matt W. Benjamin" <[email-masked]>
Date: Mon, 11 Jul 2011 14:42:56 -0400 (EDT)

Hi,

I apologize again in advance, of course it is clear how mdsthreshold helps arrive at an acceptable behavior for short writes.  However, is it really unreasonable for the client to know that it must simply send layoutcommit when it wishes to stabilize writes made at data servers?  IIUC, the client could even disregard mdsthreshold (or not implement it, it's a hint only, and its definition provides only 'should' guidance).

Regards,

Matt

----- "Trond Myklebust" <[email-masked]> wrote:

> On Mon, 2011-07-11 at 15:52 +0300, Benny Halevy wrote: 
> > On 2011-07-10 22:15, Trond Myklebust wrote:
> > > On Sun, 2011-07-10 at 14:08 +0300, Benny Halevy wrote: 
> > >> On 2011-07-09 03:18, Myklebust, Trond wrote:
> > >>>> -----Original Message-----
> > >>>> From: Sandeep Joshi [mailto:[email-masked]]
> > >>>> Sent: Friday, July 08, 2011 8:06 PM
> > >>>> To: Myklebust, Trond; Boaz Harrosh; Matt W. Benjamin
> > >>>> Cc: NFSv4
> > >>>> Subject: RE: [nfsv4] FILE_SYNC4 to the DS (Errata ID: 2751)
> > >>>>
> > >>>> It will benefit all servers, won't it?
> > >>>
> > >>> The intention was that the current code (which is the _same_ as
> the
> > >>> ordinary NFSv3 and NFSv4.0 code) would benefit all servers. It
> is
> > >>> usually easier to optimize write+commit on the server rather
> than on the
> > >>> client. As I said in my reply to Brent, I'd expect servers that
> don't
> > >>> like FILE_SYNC4 to the DS to use mdsthreshold to tell the client
> when it
> > >>> is in everyone's interest to send the short writes to the MDS.
> > >>>
> > >>
> > >> mdsthreshold (threshold4_write_iosize in particular) has no
> notion of
> > >> synchronous vs. asynchronous writes.  Your suggestion makes sense
> for
> > >> single FILE_SYNC4 writes but not necessarily for a bunch of small
> async
> > >> WRITEs optionally followed by a COMMIT (if UNSTABLE) and a
> LAYOUTCOMMIT.
> > > 
> > > OK. I've read the above paragraph over and over again and it still
> makes
> > > absolutely no sense to me.
> > > 
> > > Why would any sane client split a write up into smaller writes?
> > 
> > Sparse, discontiguous writes for example.
> 
> OK... There is plenty of space to expand mdsthreshold. If the current
> definition does not communicate your server's preferences accurately
> to
> the client, then you are free to propose new hint definitions in 4.2.
> 
> In the meantime, 4.1 is stuck with what is already defined in
> rfc5661.
> 
> Trond
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> [email-masked]
> www.netapp.com
> 
> _______________________________________________
> 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: Trond Myklebust <[email-masked]>
Date: Mon, 11 Jul 2011 14:56:04 -0400

> I apologize again in advance, of course it is clear how mdsthreshold helps arrive at an acceptable behavior for short writes.  However, is it really unreasonable for the client to know that it must…

You appear to still be living in a world where the spec doesn't exist.
I'm starting from the viewpoint that the spec exists and already sets
expectations for the server. Any other discussion is moot as far as I'm
concerned...

Trond

NetApp

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 11 Jul 2011 15:09:18 -0400

> expectations for the server. Any other discussion is moot as far as I'm

If the spec were unclear on this issue, then a clarification could be in
order, but we already did that here, and the spec is now crystal clear
as to what it expects of the server.

NetApp