linux-ext4 - Re: Any qualms about reverting 3d0518f4, ext4: New rec

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] [day] [month] [year] [list]

Date:	Wed, 04 Aug 2010 09:21:55 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andreas Dilger <adilger@...ger.ca>
CC:	"Ted Ts'o" <tytso@....edu>,
	ext4 development <linux-ext4@...r.kernel.org>,
	Wei Yongjun <yjwei@...fujitsu.com>
Subject: Re: Any qualms about reverting 3d0518f4, ext4: New rec_len encoding
 for very large blocksizes ?

Andreas Dilger wrote:
> On 2010-08-03, at 17:12, Ted Ts'o wrote:
>> On Tue, Aug 03, 2010 at 05:49:22PM -0500, Eric Sandeen wrote:
>>> As far as I know, reverting it won't break 64kb dir blocks...?
>> I seem to recall there was some confusion about what was the
>> correct way of recording a rec_len of 64k --- 0 or 65535.  So after
>> reverting the patch, we need to make sure we didn't end up breaking
>>  compatibility with (a) existing file systems and (b) what older 
>> versions of mke2fs may have generated.
> 
> Right - the newer code accepts both EXT4_MAX_REC_LEN and 0 to mean
> "blocksize".  The old code took EXT4_MAX_REC_LEN to mean "1 << 16".
> For filesystems with blocksize < 64k there is no difference, but I
> think it makes sense to continue to accept both EXT4_MAX_REC_LEN and
> "0".
> 
>>>>> (this does 200 iterations) and got this for the file
>>>>> creations:
>>>>> 
>>>>> ext4 stock:   Average = 21206.8 files/s ext4 patched: Average
>>>>> = 22822.1 files/s
>>>>> 
>>>>> This is a 7.6% improvement...
>> So one way of dealing wih this is making it an inline, and then 
>> #ifdef'ing out the more complex code if the page size is < 64k....

Ok, I'd thought about that route too (#ifdef, or whatnot) - 
I'll see if I can work it out that way.

However, #ifdef on PAGE_CACHE_SIZE didn't seem to quite work, as the 
original motivation was for the "whenever the VM allows block 
size > page size" case, I think...

-Eric

> Should it also be put under "unlikely()", or for that matter, the
> whole thing could be #ifdef'd out for PAGE_SIZE < 65536 since we
> won't magically grow blocksize > PAGE_SIZE support without knowing
> it.

> Cheers, Andreas

--
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