<html><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On 2011-10-13, at 4:30 PM, "Nathan Rutman" <<a href="mailto:Nathan_Rutman@xyratex.com">Nathan_Rutman@xyratex.com</a>> wrote:</span></div><blockquote type="cite"><div><span>On Oct 12, 2011, at 7:05 PM, Andreas Dilger wrote:</span><font class="Apple-style-span" color="#005001"><font class="Apple-style-span" color="#0023A3"><br></font></font><blockquote type="cite"><span>I'm not against this in principle, but I think it may be more difficult to actually implement before the OSD changes from Orion are landed to master. </span><br></blockquote><span></span><br><span>You mean, it will make it more difficult to land Orion changes, right? </span><br><span>Chris already has implemented the external build.</span><br></div></blockquote><div><br></div>No, I mean it will make it harder to maintain Lustre and ldiskfs separately before we get to the OSD API that has a better abstraction than the current fsfilt/lvfs interface that is used in the current Lustre code. <div><br></div><div>Granted that we don't have to change this code very often recently, it does change on occasion, and maintaining compatibility between arbitrary versions of ldiskfs and Lustre is a headache that we don't really need right now.</div><div><br></div><div>The fact that Chris has a point-in-time version of ldiskfs and Lustre that are working together is great, but given that the OSD code migration is already underway it doesn't make sense to add a lot of code churn before that happens. </div><div><br></div><div>I'm not against making this change if there is no expectation that there is lomg-term compatibility between different ldiskfs and Lustre builds. If it works, great, but if there is an interface change needed then both packages will need to be upgraded. </div><div><br></div><div>Hopefully once we have the OSD API in use for the OSS, MGS, and the ZFS is working there will be fewer API changes needed and the number of dependent package updates can be reduced.</div><div><br></div><div>Cheers, Andreas<br><div><br><blockquote type="cite"><div><blockquote type="cite"><span>In the past we also thought about making ldiskfs as a separate package, before ext4 started in the kernel. </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I've seen Prakash working on those patches but will not have time to look at them until at least next week. </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Are those patches against the master branch or against Orion? Also, what kernels are supported?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Cheers, Andreas</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 2011-10-12, at 3:44 PM, "Christopher J. Morrone" <<a href="mailto:morrone2@llnl.gov">morrone2@llnl.gov</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>We would like to see the ldiskfs tree removed from the lustre tree and </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>made an independent package. I have been floating this idea </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>unofficially for a while, but I would like to now officially propose </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>this for Lustre 2.2.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>With the OBD changes that are taking place on the Orion branch, we want </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>to make lustre be able to use any of a number of backend filesystems. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The current tree and configure tools make it very hard to build without </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>ldiskfs (instead using zfs, btrfs, or something we haven't thought of </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>yet). As part of cleaning that up, moving ldiskfs external to lustre </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>will help ensure that we don't have unnecessary dependencies crop up in </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the future.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>We have created an external package of the ldiskfs tree and put it up on </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>github:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://github.com/chaos/ldiskfs">https://github.com/chaos/ldiskfs</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>To use the new external ldiskfs package with lustre, you will also need </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>a few patches to lustre itself. There are links to the patches in this </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>jira ticket:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://jira.whamcloud.com/browse/LU-723">http://jira.whamcloud.com/browse/LU-723</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On a RHEL system, ldiskfs has a build dependency on the kernel-debuginfo </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>packages by default. That is where we find the ext4 source code.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Building should be fairly straight forward. Build and install ldiskfs </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>(in particular the lustre-ldiskfs-devel package), and then build lustre. </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The main new change to lustre is the addition of the configure option </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>"--with-ldiskfs-devel". On a RHEL system if you have the </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>lustre-ldiskfs-devel package installed, you won't need to give a path.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Note that we have not yet removed the in-tree ldiskfs. Our first step </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>was to get this working. Once this is accepted, we will be happy to </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>submit the patches to remove lustre's copy of ldiskfs and generally </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>clean up lustre's autoconf checks involving ldiskfs.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>We attempted to keep the changes minimal, so we didn't change the name </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>of the ldiskfs rpm packages. But we think is would be nice to change </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the name from "lustre-ldiskfs" to simply "ldiskfs". If we want to make </span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that change, now is the time to do it.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Chris</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Lustre-devel mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://lists.lustre.org/mailman/listinfo/lustre-devel">http://lists.lustre.org/mailman/listinfo/lustre-devel</a></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>Lustre-devel mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a></span><br></blockquote><blockquote type="cite"><span><a href="http://lists.lustre.org/mailman/listinfo/lustre-devel">http://lists.lustre.org/mailman/listinfo/lustre-devel</a></span><br></blockquote><span>______________________________________________________________________</span><br><span>This email may contain privileged or confidential information, which should only be used for the purpose for which it was sent by Xyratex. No further rights or licenses are granted to use such information. If you are not the intended recipient of this message, please notify the sender by return and delete it. You may not use, copy, disclose or rely on the information contained in it.</span><br><span></span><br><span>Internet email is susceptible to data corruption, interception and unauthorised amendment for which Xyratex does not accept liability. While we have taken reasonable precautions to ensure that this email is free of viruses, Xyratex does not accept liability for the presence of any computer viruses in this email, nor for any losses caused as a result of viruses.</span><br><span></span><br><span>Xyratex Technology Limited (03134912), Registered in England & Wales, Registered Office, Langstone Road, Havant, Hampshire, PO9 1SA.</span><br><span></span><br><span>The Xyratex group of companies also includes, Xyratex Ltd, registered in Bermuda, Xyratex International Inc, registered in California, Xyratex (Malaysia) Sdn Bhd registered in Malaysia, Xyratex Technology (Wuxi) Co Ltd registered in The People's Republic of China and Xyratex Japan Limited registered in Japan.</span><br><span>______________________________________________________________________</span><br><span></span><br><span></span><br></div></blockquote></div></div></body></html>