From jsimmons at infradead.org Thu Jun 21 15:05:52 2012 From: jsimmons at infradead.org (James Simmons) Date: Thu, 21 Jun 2012 16:05:52 +0100 (BST) Subject: [Lustre-devel] Fail to build Lustre on SUSE11 In-Reply-To: References: Message-ID: > Hello, > >   > > There is a compiling error when building Lustre rpms on SUSE11, at “make rpms”. Would you please help to check this. > > The error is like: > > /home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.c: In function “ll_setattr_raw”: > > /home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.c:1343: error: implicit declaration of function “inode_newsize_ok “ > > make[8]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.o] Error 1 > Sorry I haven't read my emails recently. Take a look at http://jira.whamcloud.com/browse/LU-1497 I have links in the ticket to patches to fix this. > make[7]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite] Error 2 > > make[6]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre] Error 2 > > make[5]: *** [_module_/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52] Error 2 > > make[5]: Leaving directory `/var/tmp/kernel-source-2.6.27.19-build/usr/src/linux-2.6.27.19-5.1' > > make[4]: *** [modules] Error 2 > > make[4]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52' > > error: Bad exit status from /var/tmp/rpm-tmp.54512 (%build) > >   > >   > > RPM build errors: > >     Bad exit status from /var/tmp/rpm-tmp.54512 (%build) > > make[1]: *** [rpms-real] Error 1 > > make[1]: Leaving directory `/home/build/lustre' > > make: *** [rpms] Error 2 > >   > > Building machine arch: x86_64 > > Distribution: SUSE 11 SP1 > > Kernel Version used for building: 2.6.27.19-5.1 > >   > > Best Regards, > > Kelly(EMC) > > > From kelly.zhang at emc.com Mon Jun 25 02:05:24 2012 From: kelly.zhang at emc.com (kelly.zhang at emc.com) Date: Sun, 24 Jun 2012 22:05:24 -0400 Subject: [Lustre-devel] Fail to build Lustre on SUSE11 In-Reply-To: References: Message-ID: Thanks, that is good. Best Regards, Kelly -----Original Message----- From: James Simmons [mailto:jsimmons at infradead.org] Sent: 2012年6月21日 23:06 To: Zhang, Kelly Cc: lustre-devel at lists.lustre.org; wc-discuss at whamcloud.com; Tang, Haiying; Liu, Xuezhao; tirrell, jerry; faibish, sorin Subject: Re: [Lustre-devel] Fail to build Lustre on SUSE11 > Hello, > >   > > There is a compiling error when building Lustre rpms on SUSE11, at “make rpms”. Would you please help to check this. > > The error is like: > > /home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.c: In function “ll_setattr_raw”: > > /home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.c:1343: error: implicit declaration of function “inode_newsize_ok “ > > make[8]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.o] Error 1 > Sorry I haven't read my emails recently. Take a look at http://jira.whamcloud.com/browse/LU-1497 I have links in the ticket to patches to fix this. > make[7]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite] Error 2 > > make[6]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre] Error 2 > > make[5]: *** [_module_/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52] Error 2 > > make[5]: Leaving directory `/var/tmp/kernel-source-2.6.27.19-build/usr/src/linux-2.6.27.19-5.1' > > make[4]: *** [modules] Error 2 > > make[4]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52' > > error: Bad exit status from /var/tmp/rpm-tmp.54512 (%build) > >   > >   > > RPM build errors: > >     Bad exit status from /var/tmp/rpm-tmp.54512 (%build) > > make[1]: *** [rpms-real] Error 1 > > make[1]: Leaving directory `/home/build/lustre' > > make: *** [rpms] Error 2 > >   > > Building machine arch: x86_64 > > Distribution: SUSE 11 SP1 > > Kernel Version used for building: 2.6.27.19-5.1 > >   > > Best Regards, > > Kelly(EMC) > > > From nathan_rutman at xyratex.com Fri Jun 29 18:58:53 2012 From: nathan_rutman at xyratex.com (Nathan Rutman) Date: Fri, 29 Jun 2012 11:58:53 -0700 Subject: [Lustre-devel] mmp unplug patch Message-ID: <5E974A8D-E444-46AE-9212-645CBC40CC4C@xyratex.com> Can anyone explain the purpose of unplug call in this patch? The first part of the patch I get, but why do we need to drop the existing queued items? Doesn't this simply result in more fragmented IO? raid5-mmp-unplug-dev.patch Force MD devices to pass SYNC reads directly to the disk instead of handling from cache. This is needed for MMP on MD RAID devices, and in theory could be accepted in the upstream kernel. Not needed for DMU. Index: linux-2.6.32-131.0.15.el6.x86_64/drivers/md/raid5.c =================================================================== --- linux-2.6.32-131.0.15.el6.x86_64.orig/drivers/md/raid5.c 2011-05-10 21:38:35.000000000 +0300 +++ linux-2.6.32-131.0.15.el6.x86_64/drivers/md/raid5.c 2011-05-20 08:26:04.000000000 +0300 @@ -2177,6 +2177,8 @@ static int add_stripe_bio(struct stripe_ bi->bi_next = *bip; *bip = bi; bi->bi_phys_segments++; + if (bio_rw_flagged(bi, BIO_RW_SYNCIO) && !forwrite) + clear_bit(R5_UPTODATE, &sh->dev[dd_idx].flags); /* force to read from disk. */ spin_unlock_irq(&conf->device_lock); spin_unlock(&sh->lock); @@ -4132,6 +4134,9 @@ static int make_request(mddev_t *mddev, bio_endio(bi, 0); } + if (bio_rw_flagged(bi, BIO_RW_SYNCIO)) + md_raid5_unplug_device(conf); + return 0; } From johann at whamcloud.com Fri Jun 29 20:43:39 2012 From: johann at whamcloud.com (Johann Lombardi) Date: Fri, 29 Jun 2012 22:43:39 +0200 Subject: [Lustre-devel] mmp unplug patch In-Reply-To: <5E974A8D-E444-46AE-9212-645CBC40CC4C@xyratex.com> References: <5E974A8D-E444-46AE-9212-645CBC40CC4C@xyratex.com> Message-ID: <20120629204339.GE19971@granier.hd.free.fr> On Fri, Jun 29, 2012 at 11:58:53AM -0700, Nathan Rutman wrote: > Can anyone explain the purpose of unplug call in this patch? I guess the intent is to make sure that the MMP block updates aren't delayed by the underlying I/O scheduler and make it to the storage system in a timely manner. > The first part of the patch I get, but why do we need to drop the existing queued items? The issue is that some I/O schedulers might not support BIO_RW_SYNC and the ones that do might still delay the request a bit, hoping to merge it with a forthcoming request. Therefore, the only way to make sure that the I/O is issued straight away is to unplug the queue. All in all, it depends on whether the I/O scheduler delay is negligible compared to the MMP update interval. > Doesn't this simply result in more fragmented IO? Yes, it might. HTH Cheers, Johann -- Johann Lombardi Whamcloud, Inc. www.whamcloud.com From nathan_rutman at xyratex.com Fri Jun 29 21:11:28 2012 From: nathan_rutman at xyratex.com (Nathan Rutman) Date: Fri, 29 Jun 2012 14:11:28 -0700 Subject: [Lustre-devel] mmp unplug patch In-Reply-To: <20120629204339.GE19971@granier.hd.free.fr> References: <5E974A8D-E444-46AE-9212-645CBC40CC4C@xyratex.com> <20120629204339.GE19971@granier.hd.free.fr> Message-ID: Thanks Johann. I think we're going to experiment with removing it... On Jun 29, 2012, at 1:43 PM, Johann Lombardi wrote: > On Fri, Jun 29, 2012 at 11:58:53AM -0700, Nathan Rutman wrote: >> Can anyone explain the purpose of unplug call in this patch? > > I guess the intent is to make sure that the MMP block updates aren't delayed by the underlying I/O scheduler and make it to the storage system in a timely manner. > >> The first part of the patch I get, but why do we need to drop the existing queued items? > > The issue is that some I/O schedulers might not support BIO_RW_SYNC and the ones that do might still delay the request a bit, hoping to merge it with a forthcoming request. Therefore, the only way to make sure that the I/O is issued straight away is to unplug the queue. > > All in all, it depends on whether the I/O scheduler delay is negligible compared to the MMP update interval. > >> Doesn't this simply result in more fragmented IO? > > Yes, it might. > > HTH > > Cheers, > Johann > -- > Johann Lombardi > Whamcloud, Inc. > www.whamcloud.com