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

Message-Id: <E451F0D5-F2FB-44A1-BA84-224D7F86F447@dilger.ca>
Date:	Tue, 3 Aug 2010 18:33:10 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	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 ?

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

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