From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: Distributed storage. Move away from char device ioctls.
Date: Sat, 15 Sep 2007 00:40:30 -0400 [thread overview]
Message-ID: <20070915044030.GA702@fieldses.org> (raw)
In-Reply-To: <46EB5ACA.5000207@garzik.org>
On Sat, Sep 15, 2007 at 12:08:42AM -0400, Jeff Garzik wrote:
> J. Bruce Fields wrote:
>> No, servers are required to support ordinary nfs operations to the
>> metadata server.
>> At least, that's the way it was last I heard, which was a while ago. I
>> agree that it'd stink (for any number of reasons) if you ever *had* to
>> get a layout to access some file.
>> Was that your main concern?
>
> I just sorta assumed you could fall back to the NFSv4.0 mode of operation,
> going through the metadata server for all data accesses.
Right. So any two pNFS implementations *will* be able to talk to each
other; they just may not be able to use the (possibly higher-bandwidth)
read/write path that pNFS gives them.
> But look at that choice in practice: you can either ditch pNFS completely,
> or use a proprietary solution. The market incentives are CLEARLY tilted in
> favor of makers of proprietary solutions.
I doubt somebody would go to all the trouble to implement pNFS and then
present their customers with that kind of choice. But maybe I'm missing
something. What market incentives do you see that would make that more
attractive than either 1) using a standard fully-specified layout type,
or 2) just implementing your own proprietary protocol instead of pNFS?
> Overall, my main concern is that NFSv4.1 is no longer an open architecture
> solution. The "no-pNFS or proprietary platform" choice merely illustrate
> one of many negative aspects of this architecture.
It's always been possible to extend NFS in various ways if you want.
You could use sideband protocols with v2 and v3, for example. People
have done that. Some of them have been standardized and widely
implemented, some haven't. You could probably add your own compound ops
to v4 if you wanted, I guess.
And there's advantages to experimenting with extensions first and then
standardizing when you figure out what works. I wish it happened that
way more often.
> Now, for the first time in NFS's history (AFAIK), the protocol is no longer
> completely specified, completely known. No longer a "closed loop."
> Private layout types mean that it is _highly_ unlikely that any OS or
> appliance or implementation will be able to claim "full NFS compatibility."
Do you know of any such "private layout types"?
This is kind of a boring argument, isn't it? I'd rather hear whatever
ideas you have for a new distributed filesystem protocol.
--b.
next prev parent reply other threads:[~2007-09-15 4:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-14 18:54 Distributed storage. Move away from char device ioctls Evgeniy Polyakov
2007-09-14 19:07 ` Jeff Garzik
2007-09-14 20:46 ` Al Boldi
2007-09-14 21:12 ` J. Bruce Fields
2007-09-14 21:14 ` Jeff Garzik
2007-09-14 21:18 ` J. Bruce Fields
2007-09-14 22:32 ` Jeff Garzik
2007-09-14 22:42 ` J. Bruce Fields
2007-09-15 4:08 ` Jeff Garzik
2007-09-15 4:40 ` J. Bruce Fields [this message]
2007-09-15 2:54 ` Mike Snitzer
2007-09-15 12:34 ` Evgeniy Polyakov
2007-09-15 12:29 ` Evgeniy Polyakov
2007-09-15 17:24 ` Andreas Dilger
2007-09-16 7:07 ` Kyle Moffett
2007-10-26 10:44 ` Evgeniy Polyakov
2007-09-16 13:43 ` Evgeniy Polyakov
2007-09-15 13:56 ` Robin Humble
2007-09-15 14:35 ` Jeff Garzik
2007-09-15 16:20 ` Robin Humble
2007-09-15 17:51 ` Andreas Dilger
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=20070915044030.GA702@fieldses.org \
--to=bfields@fieldses.org \
--cc=jeff@garzik.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@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;
as well as URLs for NNTP newsgroup(s).