[Lustre-discuss] Future of lustre 1.8.3+

Wed May 19 18:04:51 PDT 2010

Kevin, et al -

I'm both personally and professionally encouraged to hear ClusterStor stand
up and publicly state intent to support Lustre on SLES.  The million dollar
question is in regards to *server* support - in particular wrt the 2.x
series.  As a token of my interest, as well as a testament to my limited
ability to maintain this in the long run, I submit the attached patches to
the recent 1.10.0.40 beta release that enable building (and confirmed to be
runnable) the server on current SLES11 kernel (2.6.27.45-0.1-default).  One
caveat is that quota support is not compilable and appears to be a bit more
difficult job than I can probably manage.  And I most certainly didn't run
a full regression suite, but a straightforward single stream read/write
appears to work fine.

Up to .38 it was mostly monkey work - but .40 introduced additional patches
to the RHEL ext4 implementation that has more substantially diverged from
the one in current SLES11.  Perhaps SLES11SP1 will converge better...

There's perhaps a Bugzilla report where this is better posted, and tomorrow
I'll look around a bit more for that, but I felt like getting it out there
asap.  This has been a topic of much interest in my community and I'm
starting to feel a bit alone in my desire to keep SLE across the board in
my environment.  I've invested quite a bit of time and effort there and
though many are fine with black box appliances, in our research environment
I prefer to have more transparency.

Sincerely - Dardo

On 5/19/2010 11:21 AM, Kevin Canady wrote:
> Quick "Public Service Announcement"
>
> ClusterStor is and will be providing support services for SLES on both 1.8x and 2.x releases.  If anyone would like to receive additional information please contact me at kevin.canady at clusterstor.com  or 415.505.7701
>
> Best regards,
> Kevin
>
> P. Kevin Canady
> Vice President,
> ClusterStor Inc.
> 415.505.7701
> kevin.canady at clusterstor.com
>
> On May 19, 2010, at 8:01 AM, Andreas Dilger wrote:
>
>> I've used a SLES kernel on an FC install for a long time on my home
>> system. With newer distros there are also fewer changes to the base
>> kernel, so there shouldn't be as much trouble to use e.g. the SLES 11
>> SP1 kernel (2.6.32) when it is released.
>>
>> Cheers, Andreas
>>
>> On 2010-05-19, at 6:01, Heiko Schröter<schroete at iup.physik.uni-bremen.d
>> e>  wrote:
>>
>>> Am Mittwoch 19 Mai 2010, um 10:33:04 schrieben Sie:
>>>> On 2010-05-19, at 01:40, Heiko Schröter wrote:
>>>>> we would like to know which way lustre is heading.
>>>>>
>>>>>>  From the s/w repository we see that only redhat and suse ditros
>>>>>> seems to be supported.
>>>>>
>>>>> Is this the official policy of the lustre development to stick to
>>>>> (only) these two distros ?
>>>>
>>>> On the client side, we will support the main distros that our
>>>> customers are using, namely RHEL/OEL/CentOS 5.x (and 6.x after
>>>> release), and SLES 10/11.  We make a best-effort attempt to have
>>>> the client work with all client kernels, but since our resources
>>>> are limited we cannot test kernels other than the supported ones.
>>>> I don't see any huge demand for e.g. an officially-supported Ubuntu
>>>> client kernel, but there has long been an unofficial Debian lustre
>>>> package.
>>>>
>>>> On the server side, we will continue to support RHEL5.x and
>>>> SLES10/11 for the Lustre 1.8 release, and RHEL 5.x (6.x is being
>>>> worked on) for the Lustre 2.x release.  Since maintaining kernel
>>>> patches for other kernels is a lot of work, we do not attempt to
>>>> provide patches for other than official kernels.  However, there
>>>> have in the past been ports of the kernel patches to other kernels
>>>> by external contributors (e.g. FC11, FC12, etc) and this will
>>>> hopefully continue in the future.
>>>
>>> The server side is the more critical part as we are using gentoo
>>> +lustre running a vanilla kernel 2.6.22.19 with the lustre patches
>>> version 1.6.6.
>>> As far as we are concerned it would be nice to have the pathces for
>>> the "vanilla-kernels" in 1.8.3+. This would be just fine.
>>>
>>> On the other hand if maintaining is the key problem on your side
>>> what would be a major argument against using a patched sles/rhel on
>>> a lustre server not running the sles/rhel distro ?
>>> I know a lot of things can happen but are these rhel/sles patches do
>>> brake some key features of the kernel which would  only work under
>>> that specific distro ?
>>> I've positivley tested a lustre client with a sles patched kernel on
>>> a gentoo distro. But i'am a bit nervous about testing it on our live
>>> lustre server system.
>>>
>>>>
>>>>> If not, then the sun src patches are still missing in the lustre
>>>>> AND e2fsprogs branches.
>>>>
>>>> I'm not sure what you mean.  The e2fsprogs patches have always been
>>>> in a separate repository from the core Lustre code, and all of the
>>>> Lustre/ldiskfs kernel patches are in the Git repository.
>>>
>>> I know. But the patches are missing for 1.41.10 in that repo. i.e.
>>> as this here "e2fsprogs-1.41.6.sun1-patches.tgz"
>>>
>>> Thanks very much for your help.
>>> Regards
>>> Heiko
>> _______________________________________________
>> Lustre-discuss mailing list
>> Lustre-discuss at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-discuss
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lustre-sles11.patch.1.10.0.40
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20100519/9cd74b03/attachment.asc>