[Lustre-discuss] ext3 tuning on a lustre filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, I was wondering if certain ext3 tweaks can be applied to a lustre filesystem? Things like: - - reclaiming some of the reserved 5% space for non-root filesystems - - disabling automatic boot-time checks after X number of boots and having a quick check done during each boot) - - enabling full journaling I've done these things with straight up ext3 filesystems and been generally happy with the tweaks. Wondering if I should even go there with Lustre, is it worth the trouble it might cause? Thanks! - -Nick - -- Nick Jennings Technical Director Creative Motion Design www.creativemotiondesign.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkn3NecACgkQbqosUH1Nr8dczACgsP4eA0nHWRD69tRQwJzWYiiE H1AAoOHbJJjYwC/5gN4fY86zD0ygjbYc =jfmH -END PGP SIGNATURE- ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] ext3 tuning on a lustre filesystem
Nick Jennings wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, I was wondering if certain ext3 tweaks can be applied to a lustre filesystem? Things like: - - reclaiming some of the reserved 5% space for non-root filesystems This one gets done quite often - 5% is a lot when partitions are terabytes. - - disabling automatic boot-time checks after X number of boots and having a quick check done during each boot) Again, with very large disks this may be desirable. Depends on your desire for a quick boot. - - enabling full journaling No sure what you mean here. We've seen some hardware configs benefit from external journaling, this eliminates a lot of head movement in some cases. I've done these things with straight up ext3 filesystems and been generally happy with the tweaks. Wondering if I should even go there with Lustre, is it worth the trouble it might cause? Doubt any of the above would cause you 'trouble' especially reclaiming the root reservation. cliffw Thanks! - -Nick - -- Nick Jennings Technical Director Creative Motion Design www.creativemotiondesign.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkn3NecACgkQbqosUH1Nr8dczACgsP4eA0nHWRD69tRQwJzWYiiE H1AAoOHbJJjYwC/5gN4fY86zD0ygjbYc =jfmH -END PGP SIGNATURE- ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Infiniband hot spot avoidance with LMC0
Isaac Huang wrote: On Mon, Apr 27, 2009 at 12:21:41PM -0600, Nathan Dauchy wrote: Greetings, Does Lustre's o2ib LND take advantage of Infiniband's LID Mask Count (LMC) capability? Might it be included in the future? I'm looking for something similar to the MV2_USE_HSAM=1 option for Hot-Spot Avoidance with MVAPICH2. Nothing like this exists so far in the o2iblnd. Currently between any two ports there's only one QP which uses the LIDs as returned by the SM. OK, thanks for confirming, Isaac. The MVAPICH2 seems to be striping outgoing data over multiple paths and adjusting path weights dynamically based on perceived speed of the paths. We'd be interested to take a look if there's a high-level description of the mechanism. The best high-level document I can find is a presentation: Hot-Spot Avoidance with Multi-Pathing over InfiniBand: An MPI Perspective, by Abhinav Vishnu, Matthew Koop, et. al. http://nowlab.cse.ohio-state.edu/publications/conf-presentations/2007/vishnu-ccgrid07.pdf I imagine the Ohio State guys would be happy to work with you. And, if Sun's code licensing plans allow for it, you can always look at the MVAPICH code. :) -Nathan ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
