linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: "J. Bruce Fields" <bfields@fieldses.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:08:42 -0400	[thread overview]
Message-ID: <46EB5ACA.5000207@garzik.org> (raw)
In-Reply-To: <20070914224212.GJ12444@fieldses.org>

J. Bruce Fields wrote:
> On Fri, Sep 14, 2007 at 06:32:11PM -0400, Jeff Garzik wrote:
>> J. Bruce Fields wrote:
>>> On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
>>>> NFSv4.1 adds to the fun, by throwing interoperability completely out the 
>>>> window.

>>> What parts are you worried about in particular?

>> I'm not worried; I'm stating facts as they exist today (draft 13):
>>
>> NFS v4.1 does something completely without precedent in the history of NFS: 
>>  the specification is defined such that interoperability is -impossible- to 
>> guarantee.
>>
>> pNFS permits private and unspecified layout types.  This means it is 
>> impossible to guarantee that one NFSv4.1 implementation will be able to 
>> talk another NFSv4.1 implementation.

> 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.

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.  But it's a 
poor choice (really little choice at all).

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.

One of NFS's biggest value propositions is its interoperability.  To 
quote some Wall Street guys, "NFS is like crack.  It Just Works.  We 
love it."

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."

And when the proprietary portion of the spec involves something as basic 
as accessing one's own data, I consider that a fundamental flaw.  NFS is 
no longer completely open.

	Jeff




  reply	other threads:[~2007-09-15  4:08 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 [this message]
2007-09-15  4:40               ` J. Bruce Fields
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=46EB5ACA.5000207@garzik.org \
    --to=jeff@garzik.org \
    --cc=bfields@fieldses.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).