From: "J. Bruce Fields" <bfields@fieldses.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfsd: default NFSv4.2 to on
Date: Wed, 11 Feb 2015 09:54:13 -0500 [thread overview]
Message-ID: <20150211145413.GC25696@fieldses.org> (raw)
In-Reply-To: <20150211141619.GA24299@infradead.org>
On Wed, Feb 11, 2015 at 06:16:19AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 11, 2015 at 09:12:57AM -0500, J. Bruce Fields wrote:
> > I think so. That's all optional--e.g. for READ_PLUS clients can
> > determine server support using ERR_OP_NOTSUPP (or whatever it's called),
> > and for attributes they can query the supported_attributes attribute.
> > It's possible we'll never support everything in 4.2.
>
> The questions is if we need a useful subset of 4.2 to bother.
Internally the virtualization people have been interested in ALLOCATE,
SEEK, and security labels, so I'm assuming we've passed that sort of
minimum "is there any benefit at all to turning this on" threshhold.
> I doubt we'll ever bother with ADBs for example, and the copy offload
> might take a while to get everyting sorted. But exposting most
> attributes and supporting READ_PLUS sounds like important enought to
> implement before considering 4.2 ready.
I agree there's a documentation and marketing problem: it would simplify
communication with users if "this server supports 4.2" reliably meant
support for some minimum list of features. Is that what you're thinking
about?
Individual distros and other server vendors may make their own decisions
here, so I don't know if we do much about that on our own.
We could also add a little more data e.g. to /proc/self/mountstats to
help figure out stuff like "why does copying a big file go so much
faster on server X than server Y?".
--b.
next prev parent reply other threads:[~2015-02-11 14:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 16:15 [PATCH] nfsd: default NFSv4.2 to on J. Bruce Fields
2015-02-11 12:37 ` Christoph Hellwig
2015-02-11 14:12 ` J. Bruce Fields
2015-02-11 14:16 ` Christoph Hellwig
2015-02-11 14:54 ` J. Bruce Fields [this message]
2015-02-11 15:15 ` Trond Myklebust
2015-02-11 15:32 ` J. Bruce Fields
2015-02-11 18:12 ` Tom Haynes
2015-02-11 18:27 ` J. Bruce Fields
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=20150211145413.GC25696@fieldses.org \
--to=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=linux-nfs@vger.kernel.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