<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>25 янв. 2025 г., в 02:24, NeilBrown <neilb@suse.de> написал(а):</div><br class="Apple-interchange-newline"><div><div>On Thu, 23 Jan 2025, Alexey Lyahkov wrote:<br><blockquote type="cite"><br><br><br> Keeping different kernels up to date with new updates is something<br> that<br> the linux-stable team does all the time. We do it at SUSE to. It<br> isn't<br> that hard.<br> You identify which patches *need* to be backported (ideally when<br> the<br> patch is created but that isn't always easy) and you use tools to<br> help<br> you backport them.<br><br>So Lustre developers needs control all stable kernels and think which<br>patch needs back ported and send it to Distro owner <br>And for each LTS kernels on the kernel.org.. I think it increase a work<br>dramatically.<br></blockquote><br>No. Lustre developers don't need to care about the stable kernels at<br>all. The stable team does that an explicitly say they don't want it to<br>be a burden on maintainers.<br></div></div></blockquote><div>Lustre maintainers don’t needs review code which affects a Lustre? It’s something new for me.</div><div>I understand a drivers changes should don’t reviewed by lustre team.</div><div>But arch/… fs/ .. mm/... kernel/ needs attention.</div><div>Lack to review will cause a very large quality degradation after short time.</div><div>As I point early - I think none of linux maintainers have a lustre cluster to test a patches before land.</div><div>They can do test own part and how to build at all. But how it affects a Lustre? A specially in performance area.</div><div>Small examples from past.</div><div>Small optimisation for page_accessed() and LRU lists fixes a problem with ext4 bitmap in memory and improve lustre performace for 10%. Due lack of read during write. (<a href="https://lwn.net/Articles/548830/">https://lwn.net/Articles/548830/</a>)</div><div>Small change in jbd2 code - like replace list_add to list_add_tail - improve performance for 5-15% due journal handle starvation solved.</div><div>(<a href="https://www.spinics.net/lists/linux-ext4/msg84888.html">https://www.spinics.net/lists/linux-ext4/msg84888.html</a>)</div><div><br></div><div>So yes, Lustre developers can move LTS kernels as unsupported area and if it’s broken just suggest to install an out-of-tree module with supported kernel. But did linux kernel needs a broken code in tree really?</div><div><br></div><div><br></div><blockquote type="cite"><div><div>The lustre team *can* decide to have some involvement - adding Fixes<br>tags, adding Cc: stable, even submitting backports which don't apply<br>trivially. But there is no requirement from anywhere.<br><br></div></div></blockquote><blockquote type="cite"><div><div>The lustre community only need to focus on one upstream.<br></div></div></blockquote><div>And have a broken lustre client once it don’t tested. Or lustre client will hit a performance degradation.</div><div><br></div><div><br></div><div>Neil, Tim, </div><div><br></div><blockquote type="cite"><div><div>Lustre develops who work for employers who sell support for older<br>kernels might need to handle backports to those kernels and it is in<br>everybody's interest not to make that unduly different e.g. by<br>separating bug fixes from features etc.<br><br></div></div></blockquote><div>Lustre primary area is ‘older’ kernels. As I point early half of customers uses a RHEL7, second 30% is RHEL8.</div><div>And just 2% uses a modern kernels.</div><div><br></div><br><blockquote type="cite"><div><div>The lustre community may well choose to host and share those backports,<br>and maybe even include them in testing. But I suspect that would be<br>driven by vendors who sell support. It certainly wouldn't be imposed by<br>the upstream community.<br><br>Exactly how we work with distros like Redhat, SUSE, Ubuntu would depend<br>on what can be negotiated with them.<br>Some might be willing to accept backports and release them in<br>maintenance updates. Some might not.<br>In that case the way to support their kernel for your customers would be<br>to start with the source for a particular maint update, add the missing<br>patches, build, and distribute the result.<br>You probably would only need to do this for each servie-pack, not for<br>each update.<br><br>It isn't really different from what it done today, but it would be done<br>in a different way.<br><br>Thanks,<br>NeilBrown<br></div></div></blockquote></div><br></body></html>