[LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem

[LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem

[Johann Lombardi]

Hello,

I would like to attend the LSF file system track for discussing the inclusion of the Lustre filesystem in the kernel.

Lustre is a massively parallel distributed file system widely used in the High Performance Computing (HPC) world. Lustre filesystems are used in clusters ranging from small universities and company departments to large-scale supercomputers (50% of the top 500 computers run Lustre).
Lustre is available under the GNU GPL license and has a large community, with emerging open-source foundation support.
Both the Lustre client and server components run in the kernel space. Lustre servers use a modified version of ext4 as the backing filesystem, which itself has benefited from a significant number of features contributed by the Lustre team. That said, work is taking place to port Lustre to btrfs and we also would like to discuss this with the Linux filesystem developers.

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. We are now in a different situation since the Lustre client no longer requires the kernel to be patched. We are also in the process of reworking the Lustre server code to reduce or avoid the need to patch the kernel, though there are still a number of patches to ext4 that are not yet ready for integration. Therefore, i would like to discuss with the Linux filesystem developers what would need to be done to include Lustre into the upstream kernel.

Thanks,
Johann

Johann Lombardi
---------------
Johann has been a Lustre developer and technical lead of the Lustre support team for the past 4 years. He has been involved in other Linux kernel development and support since 2003, working with Bull, Cluster Filesystems, Sun, Oracle and soon Whamcloud.

Re: [LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem

[Christoph Hellwig]

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.

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.

Re: [LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem

[Andreas Dilger]

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.

Cheers, Andreas
--
Andreas Dilger 
Principal Engineer
Whamcloud, Inc.

Re: [LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem

[Christoph Hellwig]

On Wed, Feb 02, 2011 at 04:46:51PM -0700, Andreas Dilger wrote:
> 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.

Exactly.  And that's the reason why it has no business hogging away LSF
sessions.  It might be fine as a BOF session if you think you have
enough people actually doing the work around that otherwise wouldn't be,
but it really isn't anything of general interest for all filesystem
developers.

	"talk is cheap, show me the code"

Re: [LSF/MM TOPIC][ATTEND] Merging the Lustre filesystem

[Chris Mason]

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