https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2473 Lustre <p>RHEL 6.4 beta is now out, and we are beginning to assemble the next TOSS release at LLNL. I will attach patches to this ticket that add preliminary RHEL 6.4 support to ldiskfs only. In otherwords, I am updating ldiskfs/kernel_patches, not lustre/kernel_patches.</p> LU-2473

ldiskfs RHEL6.4 support

Improvement Blocker Resolved Fixed Yang Sheng Christopher Morrone HB Tue, 11 Dec 2012 20:43:49 +0000 Tue, 9 Apr 2013 13:42:36 +0000 Tue, 9 Apr 2013 13:42:36 +0000 Lustre 2.4.0 Lustre 2.4.0 0 10 <p>I pushed the following two commits:</p> <p> <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4803</a><br/> <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4804</a></p> <p>The idea is to add rhel 6.4 support without destroying the rhel 6.3 patch series. A novel idea, but one that I think is worth pursuing. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>We don't need to official "support" RHEL 6.3 once RHEL 6.4 is out of beta, but it would be nice to not intentionally destroy the patch stack for RHEL 6.3.</p> <p>This new way of doing things allows folks like LLNL that start testing new RHEL releases early to use lustre, and on the other hand also give those slow to upgrade to 6.4 a way to continue to test newer lustre version on rhel 6.3.</p> <p>NOTE: I only did a fairly naive contextual fixup of the RHEL6.4 patches in <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4804</a>. They apply and build, but an ldiskfs expert needs to look them over and make sure that they are still sane.</p> <p>Yangsheng</p> <p>Could you please comment on this?</p> <p>Thanks</p> <p>Peter</p> <p>This really is a new idea. I don't think it is a best way to handle ldiskfs patches like that. </p> <p>I used this approach to support SLES11 SP1. The SP1 support is basically RHEL6 plus one patch to handle the difference. Any fixes RHEL6 got SP1 also got. This makes maintaining much easier. So IMNSHO Chris approach is the way to go. I will be approaching <a href="https://jira.whamcloud.com/browse/LU-1812" title="3.6/FC18 Server Patches" class="issue-link" data-issue-key="LU-1812"><del>LU-1812</del></a> the same. I have to say tho I really wish we had a ldiskfs core that would apply distro specific patches instead of the reverse of the way we do it now.</p> <p>I am obviously in agreement with James. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Yang Sheng, if you have advice for a better way to do it, please elaborate.</p> <p>I agree that this is a new idea for how to handle the patches. The way that the patches have been managed in ldiskfs in the past has been rather horrible for anyone outside of Sun/Oracle/Whamcloud/Intel.</p> <blockquote><p>I have to say tho I really wish we had a ldiskfs core that would apply distro specific patches instead of the reverse of the way we do it now.</p></blockquote> <p>James, if I understand you correctly, you are suggesting that the ldiskfs package should contain the full source code from ext4, converted into ldiskfs. Not just be patches that are applied on the fly to ext4.</p> <p>At LLNL, I attempted to do that at one point. I kept the full source in a git repo. But even for a single distro, it was quite difficult to maintain. Partly that was because upstream wasn't on board with the approach. But also it was because ext4 is pretty tightly integrated with the kernel, and even seemingly minor kernel updates made large dangerous changes to ext4. Dangerous in the sense that if they were not applied to ldiskfs as well, the code would run but be subtly broken. I've seen instances of that in recent history.</p> <p>I'm not entirely opposed to that idea, but it did prove harder than I originally thought it would be.</p> <p>Yes that was what I was suggesting as a alternative. I see you have bleed trying that were I only pondering if it would be worth doing. I see the cost is to high to do that approach.</p> <p>Didn't want to clutter the comments section of the patch inspection. Since the patch needs to be refreshed I like to suggest that the unknown directory be named shared. Also I think Andreas patch cleanup code from <a href="https://jira.whamcloud.com/browse/LU-20" title="patchless server kernel" class="issue-link" data-issue-key="LU-20"><del>LU-20</del></a> will need to be updated to the new changes in the patch tree structure.</p> <p>Yes, I can do that. I'm waiting for an <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a> commit to land (any month now...) before the rebase.</p> <p>Oh actually, the first <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4803</a> can probably be rebased now instead of waiting. Its probably only <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4804</a> that has a dependency on both <a href="https://jira.whamcloud.com/browse/LU-20" title="patchless server kernel" class="issue-link" data-issue-key="LU-20"><del>LU-20</del></a> and <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a>.</p> <p>I did originally name the directory "shared" instead of "unknown". Mainly I wanted to avoid people throwing everything in "shared" in the future. I'd like to see new patches appear in the directory for the system where they were first developed.</p> <p>But it is not a strong opinion. If you like that better, I may change it back when I rebase.</p> <p>Also, I wanted to avoid the implication that the patches in other directories are NOT shared, when in fact they probably will be shared by newer revisions of the OS.</p> <p>You made valid points. Unknown is fine with me. You will need to rebased 4803 in the future again since it will collide with the patch from <a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a>. Sigh, so many colliding patches.</p> <p>I have rebased patches, but the second one has conflicts with both <a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a> and <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a>. So I either push now, and refresh the <a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a> patch (which does not belong to me), or I need to wait until <a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a> lands. I'll wait for now.</p> <p>I rebased <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">4803</a> onto the <a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a> patch. The <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a> patch will need to wait until <a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a> really lands, because it also depends on the recently landed <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a> patches.</p> <p><a href="https://jira.whamcloud.com/browse/LU-992" title="deprecate RHEL5 kernel support for Lustre 2.2 servers" class="issue-link" data-issue-key="LU-992"><del>LU-992</del></a> landed, so I rebased both patches (<a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">4803</a>, <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a>) onto master.</p> <p>Just so everyone is clear, the <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">4803</a> patch can be reviewed and landed without considering whether the the new patches to support RHEL6.4 are correct in <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a>.</p> <p>The <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">4803</a> patch just lays the groundwork to support new kernels with ldiskfs without intentionally breaking previous kernel support.</p> <blockquote><p>In fact, I more like maintain a base ldiskfs patch group. And provide a patch that contain special change to distro. That is, this patch first change base patch group, and then apply to ext4 source. If so, we can reduce the patch number. But it obviously bring some complicated things special to review.</p></blockquote> <p>That is only a slight change from what I have. And in fact, your "base" set of patches will quickly diminish each time a new OS is supported. Your solution means that when a "base" patch no longer applies to a new kernel, you need to not only make ONE copy (which is my proposal does), you will need to make a copy into EVERY existing kernel subdirectory as well as the new kernel subdirectory. Because now it is no longer a universal "base".</p> <p>How is that any better than my system?</p> <p>I think i haven't express clear enough. The 'base patch group' is not make change unless ldiskfs needed. We provide other patch contain the changes that resolved conflict when the 'base patch' apply to kernel-tree. This patch just contain distro special changes. There process just running on build system. That is, every distrio just need one patch and 'base patch'. </p> <p>I have ever produce a patch for that. As you know, since some things occured interrupt it. Please refer to: <br/> <a href="https://bugzilla.lustre.org/attachment.cgi?id=32635" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.lustre.org/attachment.cgi?id=32635</a> <br/> <a href="https://bugzilla.lustre.org/show_bug.cgi?id=24037" class="external-link" target="_blank" rel="nofollow noopener">https://bugzilla.lustre.org/show_bug.cgi?id=24037</a></p> <p>I am still not understanding what you are proposing. Do you want to do this:</p> <p>1) apply common "base" patches<br/> 2) apply distro-specific patches</p> <p>or this:</p> <p>1) apply distro-specific patches<br/> 2) apply common "base" patches</p> <p>Either way, I don't see that working particularly well. In the first case (apply "base" before "distro-specific"), it won't work because many of the patches will not apply to everything. So you wind up having MORE patch duplication than in my proposal. Because the way I do things, some patches that are shared interleave with distro-specific patches. With this option, as soon as you hit a patch that doesn't apply cleanly to ALL versions of ext4, you'll need to split it out into many distro-specific patches. In my plan, you only need to split out one copy of the patch for that one new kernel you are adding.</p> <p>In the second case (apply "distro-specific" before "base"), that just seems crazy. You would essentially be trying to turn all different versions of ext4 into a single homogenous source code base, in order to allow a "base" set of patches to apply cleanly. You would be better off just putting the source code in the the package directly.</p> <p>It just 2 steps:</p> <p>1. apply distro-special patch to 'base patches' --&gt; 'tmp patches' <br/> 2. apply 'tmp patches' to kernel-tree;</p> <p>The 'tmp patches' just exist in build process. </p> <p>I really, really don't like that idea. Trying to work with patches of patches would be quite a bit more difficult than what I am proposing. Also, I think that would be a <em>great</em> deal more difficult for gerrit reviewers to deal with.</p> <p>We already have a situation where gerrit reviewers need to review patches to patches. Your suggestion would mean that reviewers need to look at patches of patches of patches. Reviewing other people's work is hard enough. I think that would add a level of difficulty that we really do not want.</p> <p>Indeed, so I won't push it landed. Since it really difficult. </p> <p>Brian Behlendorf made a suggestion that sounded good to me. Andreas, Peter, perhaps this would address your concern about people accidentally using unsupported patch series:</p> <p>What about having an ldiskfs configure option named something like "--enable-unsupported" that would need to be set before any of the unsupported patch series are applied.</p> <p>In other words, by default, only the couple of officially "supported" series would automatically apply, and it would look to most people like what we have today. The additional unsupported series files are only recognized and applied by the build system when --enable-unsupported is used.</p> <p>It would be really nice to get change <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">4803</a> reviewed and landed ASAP. A number of other patches other depend on, or will conflict with, that patch.</p> <p>The <a href="https://jira.whamcloud.com/browse/LU-1812" title="3.6/FC18 Server Patches" class="issue-link" data-issue-key="LU-1812"><del>LU-1812</del></a> is now directly basing their work on that patch, and I'll refresh the RHEL6.4 patch here when/if that lands.</p> <p>Patch landed. close bug.</p> <p>Its not finished yet. Patch <a href="http://review.whamcloud.com/#change,4804" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,4804</a> needs to be rebased and merge yet.</p> <p>James is correct, the patch that adds the actual "ldiskfs RHEL6.4 support" has not landed (change <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a>). Only the patch that reorganizes the ldiskfs patches into subdirectories has landed (change <a href="http://review.whamcloud.com/4803" class="external-link" target="_blank" rel="nofollow noopener">4803</a>).</p> <p>I will try to get to refreshing change 4804 soon.</p> <p>I updated the RHEL6.4 ldiskfs series in change <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a>. The list of patches that needed to be changed for RHEL6.4 shrunk because I rebased this on change <a href="http://review.whamcloud.com/5001" class="external-link" target="_blank" rel="nofollow noopener">5001</a>, and because I reverted a small upstream style change in one of the early patches so later patches wouldn't need the adjustment for context.</p> <p>I believe that I addressed the previous review comments as well.</p> <p>Although this change is only necessary for rhel/centos 6.4 I've applied and tried it in centos 6.3 and sles11sp2 as well. The new selection rules in ldiskfs-build.m4 appear to work correctly everywhere.</p> <p>Awesome, thanks alot for checking that!</p> <p>For everyone watching at home, change <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a> is dependent the following series of three patches, which are pretty darn close to being ready themselves:</p> <p><a href="http://review.whamcloud.com/5675" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5675</a><br/> <a href="http://review.whamcloud.com/4991" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4991</a><br/> <a href="http://review.whamcloud.com/5001" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5001</a></p> <p>I believe that 4991 and 5001 are done. 5675 we have some mysterious failures, but the change seems pretty good to me. I'm guessing that either the failures are unrelated to the change, but perhaps we missed at spot in lustre where the new header needs to be included. We'll see how the latest rebase does in autotest.</p> <p>James found the problem with change 5675, so I am hopeful that all four changes are in their final state for landing.</p> <p>The prerequisites have all been merged. Now we just await the landing of <a href="http://review.whamcloud.com/4804" class="external-link" target="_blank" rel="nofollow noopener">4804</a>.</p> <p>As a bonus <a href="https://jira.whamcloud.com/browse/LU-3071" title="kernel BUG at fs/jbd2/transaction.c:293 (jbd2_journal_start)" class="issue-link" data-issue-key="LU-3071"><del>LU-3071</del></a> get fixed automatically when you move to RHEL6.4</p> <p>It is <a href="https://jira.whamcloud.com/browse/LU-2967" title="list_del corruption - client crashes" class="issue-link" data-issue-key="LU-2967"><del>LU-2967</del></a> that we are most concerned about with RHEL6.4</p> <blockquote><p>As a bonus <a href="https://jira.whamcloud.com/browse/LU-3071" title="kernel BUG at fs/jbd2/transaction.c:293 (jbd2_journal_start)" class="issue-link" data-issue-key="LU-3071"><del>LU-3071</del></a> get fixed automatically when you move to RHEL6.4</p></blockquote> <p>I do not think that is the case. Our Lustre 2.1.4 systems are already using RHEL6.4.</p> <p>Patch landed, close this ticket.</p> Related LU-2967 LU-20 LU-992 LU-2846 Development Rank 1|hzvdnr: Rank (Obsolete) 5819