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. I have tried patching the kernels sources with cvs, but this means maintaining our own kernel, which we would like to avoid. How others are dealing with this issue? Regards, -- ============================================================================Dimitris Zilaskos GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece Tel: +302310998988 Fax: +302310994309 http://www.grid.auth.gr =============================================================================
Dimitris, We are dealing it very similar to yours. We are using the beta version and patching it and rolling out the custom kernel. I am willing to volunteer and create kernels for lustre but we need equipment and testers. Hope this helps! On Sun, Aug 3, 2008 at 6:44 AM, Dimitris Zilaskos <dzila at tassadar.physics.auth.gr> 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. > > I have tried patching the kernels sources with cvs, but this means > maintaining our own kernel, which we would like to avoid. How others are > dealing with this issue? > > Regards, > > -- > ============================================================================> Dimitris Zilaskos > GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece > Tel: +302310998988 Fax: +302310994309 > http://www.grid.auth.gr > ============================================================================> _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss >
On Sun, 3 Aug 2008, Mag Gam wrote:> Dimitris, > > We are dealing it very similar to yours. We are using the beta version > and patching it and rolling out the custom kernel. I am willing to > volunteer and create kernels for lustre but we need equipment and > testers. > >Thank you for your reply. Have you introduced any automation in the process?> Hope this helps! > > > On Sun, Aug 3, 2008 at 6:44 AM, Dimitris Zilaskos > <dzila at tassadar.physics.auth.gr> 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. >> >> I have tried patching the kernels sources with cvs, but this means >> maintaining our own kernel, which we would like to avoid. How others are >> dealing with this issue? >>-- ============================================================================Dimitris Zilaskos GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece Tel: +302310998988 Fax: +302310994309 http://www.grid.auth.gr =============================================================================
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080805/3a705809/attachment.bin
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 =============================================================================
On Tue, 2008-08-05 at 20:30 +0300, Dimitris Zilaskos wrote:> > 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.Indeed. That is how most of our installations run and thus only remote exploits are of the very critical nature.> 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?Indeed, we highly recommend patchless clients, especially in cases where you need to remain absolutely current with errata kernels. In fact it would not be surprising if the need for security took precedence over any measurable performance impact patchless clients may have. Afterall, a performance problem at the client side can usually be remedied by adding more clients. There''s no such remedy for security issues. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080805/e366a638/attachment.bin