linux-ext4 - Re: [PATCH 2/4] Create the journal in the middle of the filesystem

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, 03 Sep 2008 10:08:04 -0400
From:	Ric Wheeler <rwheeler@...hat.com>
To:	rwheeler@...hat.com
CC:	Theodore Tso <tytso@....edu>,
	Frédéric Bohé <frederic.bohe@...l.net>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/4] Create the journal in the middle of the filesystem

Ric Wheeler wrote:
> Theodore Tso wrote:
>> On Thu, Aug 28, 2008 at 09:40:30AM -0400, Ric Wheeler wrote:
>>  
>>> I can try and test this with my fsync() heavy fs_mark run...
>>>
>>>     
>>
>> Given [1] I have no doubt that you should see a difference between
>> mke2fs from e2fsprogs 1.41.0 (which will allocate the journal at the
>> beginning of the filesystem) and the latest tip of e2fsprogs.
>>
>> It would be interesting to see how measurable the difference is,
>> though.  I'd recommend doing "mke2fs -t ext4dev" using both versions
>> of mke2fs, and seeing how much the difference it makes.
>>
>> [1] 
>> http://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran_html/main.html#fig-journal-location-withinfs-fix 
>>
>>
>>                             - Ted
>>
>>   
>
> I was thinking of trying this on a much larger disk (1TB) - the 
> article reports on a 4GB partition which is pretty tiny,
>
> ric
Using Ted's new journal in the middle mkfs & hacking it slightly to make 
the journal go back to block 0, I ran some quick tests to try and 
measure an impact of the journal placement (multiple threads writing 4MB 
files).

The results that are most clear are certainly that delayed allocation is 
a big win, the journal placement has mostly a positive impact on the 
write performance, but the results are quite close.


Starting with a newly created file system, each pass put down 16,000 4MB 
files:


 Count     Files/sec - ZERO    Files/sec - Middle
 16000         20.8                   20.8
 32000         19.2                   18.4
 48000         16.0                   14.4
 64000         20.8                   20.8
 80000         20.8                   20.8
 96000         20.8                   20.8
112000         20.8                   20.8
128000         19.2                   20.8
144000         19.2                   19.2
160000         17.6                   19.2
176000         16.6                   17.6
192000         16.0                   16.0
208000         14.4                   14.4
224000         12.8                   14.4


With no delayed allocation:

Count     Files/sec - ZERO    Files/sec - Middle
 16000         16.0                   16.0
 32000         16.0                   16.0
 48000         16.0                   16.0
 64000         16.0                   14.8
 80000         14.4                   14.4
 96000         14.1                   14.4
112000         12.8                   12.8
128000         11.2                   11.2
144000         11.2                   12.8
160000         14.4                   14.4
176000         11.3                   12.8
192000         14.9                   12.8
208000         16.0                   16.0
224000         14.4                   16.0

ric

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