linux-ext4 - Re: [PATCH] ext4: optimize extent selection for block removal in case of hole punch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130619140605.GA24194@thunk.org>
Date:	Wed, 19 Jun 2013 10:06:05 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Ashish Sangwan <ashishsangwan2@...il.com>
Cc:	adilger@...ger.ca, ext4 development <linux-ext4@...r.kernel.org>,
	Ashish Sangwan <a.sangwan@...sung.com>,
	Namjae Jeon <namjae.jeon@...sung.com>
Subject: Re: [PATCH] ext4: optimize extent selection for block removal in
 case of hole punch

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 <tytso@....edu> wrote:
> > On Fri, May 24, 2013 at 08:09:17PM +0530, ashishsangwan2@...il.com wrote:
> >> From: Ashish Sangwan <a.sangwan@...sung.com>
> >>
> >> 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 <a.sangwan@...sung.com>
> >> Signed-off-by: Namjae Jeon <namjae.jeon@...sung.com>
> >
> > 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.

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.

Regards,

						- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html