From: Ashish Sangwan Subject: Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch Date: Wed, 19 Jun 2013 21:14:53 +0530 Message-ID: References: <519f7ba2.04fc440a.06c2.ffffd589@mx.google.com> <20130618154053.GF7359@thunk.org> <20130619140605.GA24194@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: adilger@dilger.ca, ext4 development , Ashish Sangwan , Namjae Jeon To: "Theodore Ts'o" Return-path: Received: from mail-qa0-f43.google.com ([209.85.216.43]:41875 "EHLO mail-qa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756632Ab3FSPox (ORCPT ); Wed, 19 Jun 2013 11:44:53 -0400 Received: by mail-qa0-f43.google.com with SMTP id d13so516863qak.9 for ; Wed, 19 Jun 2013 08:44:53 -0700 (PDT) In-Reply-To: <20130619140605.GA24194@thunk.org> Sender: linux-ext4-owner@vger.kernel.org List-ID: On Wed, Jun 19, 2013 at 7:36 PM, Theodore Ts'o wrote: > On Wed, Jun 19, 2013 at 07:15:35PM +0530, Ashish Sangwan wrote: >> On Tue, Jun 18, 2013 at 9:10 PM, Theodore Ts'o wrote: >> > On Fri, May 24, 2013 at 08:09:17PM +0530, ashishsangwan2@gmail.com wrote: >> >> From: Ashish Sangwan >> >> >> >> Both hole punch and truncate use ext4_ext_rm_leaf for removing >> >> blocks. Currently we choose the last extent as the starting >> >> point for removing blocks: ex = EXT_LAST_EXTENT(eh); >> >> This is OK for truncate but for hole punch we can optimize the >> >> extent selection as the path is already initialized. >> >> We could use this information to select proper starting extent. >> >> The code change in this patch will not affect truncate as for >> >> truncate path[depth].p_ext will always be NULL. >> >> >> >> Signed-off-by: Ashish Sangwan >> >> Signed-off-by: Namjae Jeon >> > >> > Applied, thanks. >> >> Sorry I cannot see the patch changes in ext4 dev branch. > > Sorry, I dropped this patch from the dev branch last night, but I > didn't want to send e-mail about it until I had completed enough > testing to be sure. It appears that this patch is causing a > regression; xfstests generic/269 and generic/279 to fail in the > nojournal configuration. > Dropping this patch makes sense until root cause is not obvious. > The tests are ones which have multiple fsstress threads racing with > dd/ENOSPC hitters, with (#270) and without (#269) quota enabled. It's > not at all obvious to me why your particular change would make a > difference here, and it may simply be that your optimization is > exposing a timing change and is not the root cause of the failure, but > I'm going to move this to the unstable portion of the patch series > until we do further investigation. > > If you could take a look at this, I would appreciate it, but as I > said, this may very well turn out not be the fault of your patch. > Sure, I will try looking into it. Regards, Ashish > Regards, > > - Ted >