[Lustre-devel] Moving ldiskfs external to the Lustre tree
adilger at whamcloud.com
Thu Oct 13 20:09:59 PDT 2011
On 2011-10-13, at 9:41 AM, Prakash Surya <surya1 at llnl.gov> wrote:
> On Wed, Oct 12, 2011 at 07:05:51PM -0700, Andreas Dilger wrote:
>> I'm not against this in principle, but I think it may be more difficult to actually implement before the OSD changes from Orion are landed to master. In the past we also thought about making ldiskfs as a separate package, before ext4 started in the kernel.
>> I've seen Prakash working on those patches but will not have time to look at them until at least next week.
>> Are those patches against the master branch or against Orion? Also, what kernels are supported?
> The patches for Lustre are against master. I believe our plan is to
> have the patches landed and working on master, before we officially
> integrate them into Orion.
> As far as supported kernels, I've tried to keep that consistent with
> what is already supported; although I admit most testing so far has
> been done on RHEL.
> What kernels are officially supported by Whamcloud? What kernels does it
> need to support?
So far we only support servers with RHEL-like kernels, but I've also seen patches for SLES kernels submitted, so I don't want to rule those out.
Like I previously wrote, I'm not against the patches in principle, but I haven't had a chance to look at the changes themselves yet since I'm on vacation and not supposed to be working...
Have you had the ldiskfs module externally working for a while? How much effort is it to coordinate changes in ldiskfs (exports, API changes, etc) with Lustre?
>> On 2011-10-12, at 3:44 PM, "Christopher J. Morrone" <morrone2 at llnl.gov> wrote:
>>> We would like to see the ldiskfs tree removed from the lustre tree and
>>> made an independent package. I have been floating this idea
>>> unofficially for a while, but I would like to now officially propose
>>> this for Lustre 2.2.
>>> With the OBD changes that are taking place on the Orion branch, we want
>>> to make lustre be able to use any of a number of backend filesystems.
>>> The current tree and configure tools make it very hard to build without
>>> ldiskfs (instead using zfs, btrfs, or something we haven't thought of
>>> yet). As part of cleaning that up, moving ldiskfs external to lustre
>>> will help ensure that we don't have unnecessary dependencies crop up in
>>> the future.
>>> We have created an external package of the ldiskfs tree and put it up on
>>> To use the new external ldiskfs package with lustre, you will also need
>>> a few patches to lustre itself. There are links to the patches in this
>>> jira ticket:
>>> On a RHEL system, ldiskfs has a build dependency on the kernel-debuginfo
>>> packages by default. That is where we find the ext4 source code.
>>> Building should be fairly straight forward. Build and install ldiskfs
>>> (in particular the lustre-ldiskfs-devel package), and then build lustre.
>>> The main new change to lustre is the addition of the configure option
>>> "--with-ldiskfs-devel". On a RHEL system if you have the
>>> lustre-ldiskfs-devel package installed, you won't need to give a path.
>>> Note that we have not yet removed the in-tree ldiskfs. Our first step
>>> was to get this working. Once this is accepted, we will be happy to
>>> submit the patches to remove lustre's copy of ldiskfs and generally
>>> clean up lustre's autoconf checks involving ldiskfs.
>>> We attempted to keep the changes minimal, so we didn't change the name
>>> of the ldiskfs rpm packages. But we think is would be nice to change
>>> the name from "lustre-ldiskfs" to simply "ldiskfs". If we want to make
>>> that change, now is the time to do it.
>>> Lustre-devel mailing list
>>> Lustre-devel at lists.lustre.org
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lustre-devel