[Lustre-discuss] lustre and latest errata kernel

[Dimitris Zilaskos]

 	Dear Brian,

I can understand very well the reasons for the lag between the releases of 
lustre-patched kernels based on an errata versions. We also do not apply 
errata kernels as timely as we wish, since our clusters serve important jobs
that can last several days or weeks. But there is the issue of what to do in
case of that extremely critical bug that must be dealt with immediately, so
we are trying to come up with a strategy for that.

Since the systems serving as file servers will be dedicated to that 
purpose and thus not be accessible to others but only to staff, it is my 
view that it would be adequate to run Sun provided kernels on them. 
For systems that act as clients and are open to users, I am evaluating the 
patchless lustre client option under our workloads. If the performance 
difference is acceptable, we may stick with it. Do you, or any other, have 
any comment on this approach?


Regards,

On Tue, 5 Aug 2008, Brian J. Murrell wrote:

> On Sun, 2008-08-03 at 13:44 +0300, Dimitris Zilaskos wrote:
>> 	Hi,
>>
>> We are investigating the possibility of deploying lustre in our clusters.
>> We are using RHEL4. An important issue we are facing is support for the
>> latest errata kernels. For example at the moment it is possible to download
>> lustre-patched 2.6.9-67.0.7 kernel, while the latest errata is 2.6.9-78.
>
> We strive to maintain currency with vendor errata kernels but a couple
> of factors impede us in being as timely as I'm sure you wish we would
> be.
>
> The first is that we don't get an errata kernel any quicker than you do.
> RH for example don't make any early releases for anyone, so we can only
> start integration and testing when the kernel is released to the general
> public.  This process can take a couple of weeks for us to do a full QA
> array of testing, which I'm sure you can appreciate the result of --
> knowing that any given release has been through our rigorous testing in
> order to minimize as much as we can the unfortunate event of upgrade
> failures.
>
> The second impediment is timing.  Sometimes an errata kernel is released
> too late to make it for the feature freeze for an upcoming release even
> though that release could be a couple of weeks (remember, QA) away.
> This gives the appearance that we take a long time to get an errata
> release out since it won't come out now until our next regularly
> scheduled release.
>
> Sometimes we will do a point release for nothing else than to support a
> very important errata kernel but that doesn't happen entirely often.
>
> b.
>
>

-- 
=============================================================================
Dimitris Zilaskos
GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece
Tel: +302310998988 Fax: +302310994309
http://www.grid.auth.gr 
=============================================================================