linux-ext4 - Re: generic/064 test failures on ext4 (4.2-rc*)

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]

Date:	Mon, 27 Jul 2015 23:09:13 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Eric Whitney <enwlinux@...il.com>, namjae.jeon@...sung.com,
	a.sangwan@...sung.com, linux-ext4@...r.kernel.org,
	fstests@...r.kernel.org
Subject: Re: generic/064 test failures on ext4 (4.2-rc*)

On Tue, Jul 28, 2015 at 07:51:29AM +1000, Dave Chinner wrote:
> The block layout outside the insert range should not be modified at
> all, so if inserting 100 holes results in more data extents that the
> expected 100, then there's something wrong before we start inserting
> holes.  e.g. maybe the source file had two extents rather than 1.
> Can you confirm that this is occurring?

Yes, that's what is going on.  If delayed allocation is disabled (as
it is in some configuration scenarios), ext4's block allocator doesn't
do as well, and in some cases it will pick a starting block number for
the file that ends up splitting the initial file across block groups'
meta data blocks.

> Really, the number of extents or holes at the intermediate stage
> doesn't matter. What matters is that after collapsing the holes back
> out of the file, then number of extents is identical to the original
> file (i.e. that fcollapse() undoes finsert() exactly).

Yup.

> So changing this code to use _within_tolerance to say that 100 >=
> num_extents >= 105 is ok would probably be better:
> 
> 	_within_tolerance "Extent count" $nextents 100 0 5%
> 
> This will output a standard pass/fail message rather than an exact
> count.  This allows some wiggle room for filesystem configurations
> that have unexpected non-contiguous baseline allocation behaviour to
> pass the test.

Works for me.

Thanks,

					- 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