linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Andreas Dilger <adilger@whamcloud.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	lsf-pc <lsf-pc@lists.linuxfoundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem
Date: Mon, 14 Feb 2011 10:26:58 -0500	[thread overview]
Message-ID: <1297697136-sup-8513@think> (raw)
In-Reply-To: <D49ADD26-9C4E-479E-B80C-ACB132B407E8@whamcloud.com>

Excerpts from Andreas Dilger's message of 2011-02-02 18:46:51 -0500:
> On 2011-02-02, at 07:59, Christoph Hellwig wrote:
> > On Wed, Feb 02, 2011 at 03:14:31PM +0100, Johann Lombardi wrote:
> >> In the past, there were ongoing discussions about merging the Lustre code into the kernel, but they failed due to the significant changes required to the kernel at that time.
> > 
> > That's utter nonsense.  The only thing that failed was pushing hooks
> > without in-tree users that would only benefit lustre.  If you're serious
> > about merging Lustre clean up the mess that it is right now and submit
> > it.
> 
> The point is that both the kernel and Lustre have changed enough that kernel patches are no longer needed on the client, and we are working toward removing the kernel patches on the server.  At that point it would be possible to merge Lustre as an isolated (though very large) filesystem.
> 
> > Boring us all with a talk why you might eventually do something to get
> > it merged is not productive.  Instead start the actualy work NOW and let
> > the code speak.
> 
> What we are trying to avoid is changing all of the Lustre code, and two years from now you say "you did this completely wrong, you should do it differently".  Also, there are a bunch of changes/features we have made for ext4 that we want to get merged upstream (large xattrs, stack reduction, multi-mount protection, etc).  Finally, we would like to start using btrfs for a backing filesystem, and we'd like to get some discussion/consensus about the design of those changes so that they can also be accepted upstream.
> 
> If you think you will be bored, you can go to the block/SCSI discussion.

Changes for ext4 and/or btrfs are still interesting, both in a
discussion of the existing patches or pushes for future design work.

-chris

      parent reply	other threads:[~2011-02-14 15:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-02 14:14 [LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem Johann Lombardi
2011-02-02 14:59 ` Christoph Hellwig
2011-02-02 23:46   ` Andreas Dilger
2011-02-12  7:15     ` Christoph Hellwig
2011-02-14 15:26     ` Chris Mason [this message]

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=1297697136-sup-8513@think \
    --to=chris.mason@oracle.com \
    --cc=adilger@whamcloud.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linuxfoundation.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).