From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Lars Marowsky-Bree <lmb@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
"Peter J. Braam" <braam@clusterfs.com>,
linux-kernel@vger.kernel.org, axboe@suse.de, kevcorry@us.ibm.com,
arjanv@redhat.com, iro@parcelfarce.linux.theplanet.co.uk,
anton@samba.org, lustre-devel@clusterfs.com
Subject: Re: [PATCH/RFC] Lustre VFS patch, version 2
Date: Thu, 03 Jun 2004 07:49:01 -0700 [thread overview]
Message-ID: <1086274140.3798.37.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20040603141922.GI4423@marowsky-bree.de>
På to , 03/06/2004 klokka 07:19, skreiv Lars Marowsky-Bree:
> The hooks (once cleaned up, no disagreement here, the technical feedback
> so far has been very valuable and continues to be) are useful and in
> effect needed not just for Lustre, but in principle for all cluster
> filesystems, such as (Open)GFS and others, even potentially NFS4 et al.
>
> The logic that _all_ modules and functionality need to be "in the tree"
> right from the start for hooks to be useful is flawed, I'm afraid. Pure
> horror that a proprietary cluster file system might also profit from it
> is not, exactly, a sound technical argument. (I can assure you I don't
> care at all for the proprietary cluster-fs.)
Whereas I agree that NFSv4 could use some of this (I'm mainly interested
in the intent_release() stuff in order to fix up an existing race), I
also agree with Christoph on the principle that having in-tree users
right from the start should be the norm rather than the exception.
Otherwise, exactly what is the plan for how to determine when an
interface is obsolete? Are we going to rely on all the out-of-tree
vendors to collectively step up and say "by the way - we're not using
this anymore."?
Cheers,
Trond
next prev parent reply other threads:[~2004-06-03 14:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-02 23:15 Peter J. Braam
2004-06-03 13:59 ` Christoph Hellwig
2004-06-03 14:19 ` Lars Marowsky-Bree
2004-06-03 14:26 ` Christoph Hellwig
2004-06-03 14:33 ` Christoph Hellwig
2004-06-03 14:49 ` Trond Myklebust [this message]
2004-06-03 18:10 ` Jan Harkes
2004-06-04 5:03 ` Daniel Phillips
2004-06-03 14:27 ` Christoph Hellwig
2004-06-04 16:55 ` Anton Blanchard
2004-06-07 18:02 ` Dipankar Sarma
2004-06-03 15:53 Peter J. Braam
2004-06-06 17:00 ` Christoph Hellwig
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=1086274140.3798.37.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=anton@samba.org \
--cc=arjanv@redhat.com \
--cc=axboe@suse.de \
--cc=braam@clusterfs.com \
--cc=hch@infradead.org \
--cc=iro@parcelfarce.linux.theplanet.co.uk \
--cc=kevcorry@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@suse.de \
--cc=lustre-devel@clusterfs.com \
/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
all inboxes | Powered by JetHome®