Linux NFS development
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: Shehjar Tikoo <shehjart-YbfuJp6tym7X/JP9YwkgDA@public.gmane.org>,
	linux-nfs@vger.kernel.org
Subject: Re: Doc for adding new NFS export option
Date: Wed, 9 Jul 2008 11:02:34 -0400	[thread overview]
Message-ID: <20080709150234.GA5780@fieldses.org> (raw)
In-Reply-To: <18548.14177.493986.264761-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>

On Wed, Jul 09, 2008 at 01:58:25PM +1000, Neil Brown wrote:
> NFSv3 writes do not have to be stable.  The client will usually
> request DATA_UNSTABLE, and then send a COMMIT a while later.  This
> should give the filesystem time to do delayed allocation.
> NFSv4 is much the same.
> NFSv2 does require stable writes, but it should not be used by anyone
> interested in good write performance on large files.
> 
> It isn't clear to me that this is something that should be an option
> in /etc/exports.
> When would a sysadmin want to turn it off?  Or if a sysadmin did want
> control, sure the level of control required would be the size of the
> preallocation. 

An export option might be a useful for testing as a way to get quick
before vs after comparisons.

But, yeah, before merging it into mainline it'd be better if it was
something that could safely just be turned on all the time.

--b.

> 
> I would strongly suggest demonstrating that you can improve some
> measure of performance using preallocation before you even begin to
> think about having an export option to select it.
> 
> NeilBrown
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2008-07-09 15:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07  3:39 Doc for adding new NFS export option Shehjar Tikoo
2008-07-07  6:29 ` Neil Brown
     [not found]   ` <18545.47041.516146.605353-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-07-09  2:45     ` Shehjar Tikoo
2008-07-09  3:58       ` Neil Brown
     [not found]         ` <18548.14177.493986.264761-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-07-09 15:02           ` J. Bruce Fields [this message]
2008-07-09 22:30           ` Shehjar Tikoo
     [not found]             ` <48753C1A.3030402-YbfuJp6tym7X/JP9YwkgDA@public.gmane.org>
2008-07-09 23:40               ` Chuck Lever
     [not found]                 ` <76bd70e30807091640q179617b8s749742bd2f10097d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-10 23:40                   ` Shehjar Tikoo
     [not found]                     ` <48769E02.3020900-YbfuJp6tym7X/JP9YwkgDA@public.gmane.org>
2008-07-11  4:31                       ` Chuck Lever
     [not found]                         ` <76bd70e30807102131w190145d7nece35402050be860-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-11 12:32                           ` Shehjar Tikoo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080709150234.GA5780@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=shehjart-YbfuJp6tym7X/JP9YwkgDA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox