Picking up from something that was said at SC last week I believe it was Andreas that mentioned the possibility of patch-less kernel support. This is something that would be immensely useful to us for a variety of reasons. Has there been any recent work into investigating how much work would be involved in implementing this and what''s the feeling for if it could be done though changes to Lustre only or a case of submitting a number of patches upstream? Ashley.
Ashley, I don''t clearry understand what you want, if you say about patchless support on client - typical size of adding support of one new kernel to pachless client is ~40kb of patch for lustre. Sometimes is has more work, sometimes less. As last lustre supported kernel is 2.6.32 - you should be plan to have ~150kb patch for 2.6.37 kernel support. if you say about patchless kernel support - yes, that is possible, but that is need more work and submiting lots patches in kernel upstream. On Nov 25, 2010, at 15:18, Ashley Pittman wrote:> > Picking up from something that was said at SC last week I believe it was Andreas that mentioned the possibility of patch-less kernel support. This is something that would be immensely useful to us for a variety of reasons. > > Has there been any recent work into investigating how much work would be involved in implementing this and what''s the feeling for if it could be done though changes to Lustre only or a case of submitting a number of patches upstream? > > Ashley. > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss
On 25 Nov 2010, at 14:04, Alexey Lyashkov wrote:> Ashley, > > I don''t clearry understand what you want, if you say about patchless support on client - > typical size of adding support of one new kernel to pachless client is ~40kb of patch for lustre. > Sometimes is has more work, sometimes less. > As last lustre supported kernel is 2.6.32 - you should be plan to have ~150kb patch for 2.6.37 kernel support.I hadn''t realise it was this much work for tracking client versions!> if you say about patchless kernel support - yes, that is possible, but that is need more work and submiting lots patches in kernel upstream.Yes this is what I meant, patchless kernel support. It was mentioned at SC that this might be possible and I was looking for more information on the type of changes and scale of work which would be involved to do this. There was the suggestion made that Lustre was originally written against much older kernels and that given increased functionality exported in modern kernels it would be possible to reduce or perhaps even eliminate the kernel patches entirely and my question was asking if anybody has done a feasibility study into this and if so would they be willing to publish the conclusions. Ashley,
Hi all, I think Ashley means patchless server support. That is already tracked in bug#21524. Ashley, while patchless server suppoert certainly is a good idea, it might not always be as helpful as you believe. Updating the presently existing patches is usually rather straight forward. Far more difficult is if the VFS changes and new methods and configure checks have to be implemented in Lustre. That made it so difficult to update Lustre to 2.6.24 and now again the limit had been 2.6.32 (maybe the VFS changes already had been in before, but I didn''t track linux-git recently that much). And those changes in the VFS are often also completely unrelated to kernel patches... I also planned to work on the sd_io stats. But I think that patch simply should be dropped in favour of blktrace. Current blkiomon does almost the same as the sd_io stats, but IMHO neither of both approaches is really helpful. So I have a modified blkiomon version (not ready for patch submission yet), that does similar stats as the DDN S2A controllers and IMHO only those detailed stats are really helpful to analyze IO patterns. If it comes to me, neither sd_io stats, nor DDN SFA nor upstream blkiomon have sufficiently detailed information to see where the problem is. I understand that blktrace has some overhead compared to sd_io stats. However, if sd_io stats is supposed to ever land upstream, it needs to be rewritten from procfs to debugfs. I think even sysfs is not suitable for it. Cheers, Bernd On Thursday, November 25, 2010, Alexey Lyashkov wrote:> Ashley, > > I don''t clearry understand what you want, if you say about patchless > support on client - typical size of adding support of one new kernel to > pachless client is ~40kb of patch for lustre. Sometimes is has more work, > sometimes less. > As last lustre supported kernel is 2.6.32 - you should be plan to have > ~150kb patch for 2.6.37 kernel support. if you say about patchless kernel > support - yes, that is possible, but that is need more work and submiting > lots patches in kernel upstream. > > On Nov 25, 2010, at 15:18, Ashley Pittman wrote: > > Picking up from something that was said at SC last week I believe it was > > Andreas that mentioned the possibility of patch-less kernel support. > > This is something that would be immensely useful to us for a variety of > > reasons. > > > > Has there been any recent work into investigating how much work would be > > involved in implementing this and what''s the feeling for if it could be > > done though changes to Lustre only or a case of submitting a number of > > patches upstream? > > > > Ashley. > > _______________________________________________ > > 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-- Bernd Schubert DataDirect Networks
Ashley You are correct. Andreas has outlined the work that is required in bz 21524 Peter Ashley Pittman wrote:> On 25 Nov 2010, at 14:04, Alexey Lyashkov wrote: > > >> Ashley, >> >> I don''t clearry understand what you want, if you say about patchless support on client - >> typical size of adding support of one new kernel to pachless client is ~40kb of patch for lustre. >> Sometimes is has more work, sometimes less. >> As last lustre supported kernel is 2.6.32 - you should be plan to have ~150kb patch for 2.6.37 kernel support. >> > > I hadn''t realise it was this much work for tracking client versions! > > >> if you say about patchless kernel support - yes, that is possible, but that is need more work and submiting lots patches in kernel upstream. >> > > Yes this is what I meant, patchless kernel support. It was mentioned at SC that this might be possible and I was looking for more information on the type of changes and scale of work which would be involved to do this. There was the suggestion made that Lustre was originally written against much older kernels and that given increased functionality exported in modern kernels it would be possible to reduce or perhaps even eliminate the kernel patches entirely and my question was asking if anybody has done a feasibility study into this and if so would they be willing to publish the conclusions. > > Ashley, > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss > >
Bernd, please don''t forget about ldiskfs patches, that is need ~1-2 days to port to new kernel. On Nov 25, 2010, at 17:38, Bernd Schubert wrote:> Hi all, > > I think Ashley means patchless server support. That is already tracked in > bug#21524. > > > -- > Bernd Schubert > DataDirect Networks
Hello Alexey, no, I didn''t forget about that. But ldiskfs is often still rather easy compared to the other generic Lustre patches required for new kernels. I also have to admit, that I''m not particulary happy about the recent number of ext4- ldiskfs patches Lustre has. But yes, I can understand the pain to get patches upstream. And even while I''m leaving right now and will work on another filesystem, I still plan to help to submit MMP upstream. Cheers, Bernd On Thursday, November 25, 2010, Alexey Lyashkov wrote:> Bernd, > > please don''t forget about ldiskfs patches, that is need ~1-2 days to port > to new kernel. > > On Nov 25, 2010, at 17:38, Bernd Schubert wrote: > > Hi all, > > > > I think Ashley means patchless server support. That is already tracked in > > bug#21524.-- Bernd Schubert DataDirect Networks
On 11/25/10 8:18 PM, Ashley Pittman wrote:> Picking up from something that was said at SC last week I believe it was Andreas that mentioned the possibility of patch-less kernel support. This is something that would be immensely useful to us for a variety of reasons. > > Has there been any recent work into investigating how much work would be involved in implementing this and what''s the feeling for if it could be done though changes to Lustre only or a case of submitting a number of patches upstream?I have made some small investigation for the patchless-server recently. I am not sure whether you can check the following link or not: http://jira.whamcloud.com/browse/IT-13 Cheers, -- Nasf> Ashley. > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss
On 25 Nov 2010, at 15:37, Fan Yong wrote:> On 11/25/10 8:18 PM, Ashley Pittman wrote: >> Picking up from something that was said at SC last week I believe it was Andreas that mentioned the possibility of patch-less kernel support. This is something that would be immensely useful to us for a variety of reasons. >> >> Has there been any recent work into investigating how much work would be involved in implementing this and what''s the feeling for if it could be done though changes to Lustre only or a case of submitting a number of patches upstream? > I have made some small investigation for the patchless-server recently.> I am not sure whether you can check the following link or not: > http://jira.whamcloud.com/browse/IT-13No I can''t, my account doesn''t have the permissions required to read that. The Oracle bug 21524 is what I think I was looking for but the more information I have on this subject the better. Ashley.
On 11/25/10 11:55 PM, Ashley Pittman wrote:> On 25 Nov 2010, at 15:37, Fan Yong wrote: > >> On 11/25/10 8:18 PM, Ashley Pittman wrote: >>> Picking up from something that was said at SC last week I believe it was Andreas that mentioned the possibility of patch-less kernel support. This is something that would be immensely useful to us for a variety of reasons. >>> >>> Has there been any recent work into investigating how much work would be involved in implementing this and what''s the feeling for if it could be done though changes to Lustre only or a case of submitting a number of patches upstream? >> I have made some small investigation for the patchless-server recently. >> I am not sure whether you can check the following link or not: >> http://jira.whamcloud.com/browse/IT-13 > No I can''t, my account doesn''t have the permissions required to read that.Sorry, it was internal task (IT) originally, and has been converted to LU type, any registered user can access it now. http://jira.whamcloud.com/browse/LU-20 Cheers, -- Nasf> The Oracle bug 21524 is what I think I was looking for but the more information I have on this subject the better. > > Ashley. >