From: Jeff Garzik <jeff@garzik.org>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
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: Fri, 14 Sep 2007 18:32:11 -0400 [thread overview]
Message-ID: <46EB0BEB.2090808@garzik.org> (raw)
In-Reply-To: <20070914211828.GC12444@fieldses.org>
J. Bruce Fields wrote:
> On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
>> J. Bruce Fields wrote:
>>> On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
>>>> I've been waiting for years for a smart person to come along and write a
>>>> POSIX-only distributed filesystem.
>>> What exactly do you mean by "POSIX-only"?
>> Don't bother supporting attributes, file modes, and other details not
>> supported by POSIX. The prime example being NFSv4, which is larded down
>> with Windows features.
>
> I am sympathetic.... Cutting those out may still leave you with
> something pretty complicated, though.
Far less complicated than NFSv4.1 though (which is easy :))
>> 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.
Even if Linux supports the entire NFSv4.1 RFC (as it stands in draft 13
anyway), there is no guarantee at all that Linux will be able to store
and retrieve data, since it's entirely possible that a proprietary
protocol is required to access your data.
NFSv4.1 is no longer a completely open architecture.
Jeff
next prev parent reply other threads:[~2007-09-14 22:32 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 [this message]
2007-09-14 22:42 ` J. Bruce Fields
2007-09-15 4:08 ` Jeff Garzik
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=46EB0BEB.2090808@garzik.org \
--to=jeff@garzik.org \
--cc=bfields@fieldses.org \
--cc=johnpol@2ka.mipt.ru \
--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).