linux-ext4 - Re: What represent 646345728 bytes

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: <4B67347C.3030103@redhat.com>
Date:	Mon, 01 Feb 2010 14:07:24 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	paul.chavent@...c.net
CC:	linux-ext4@...r.kernel.org
Subject: Re: What represent 646345728 bytes

paul.chavent@...c.net wrote:
> Thank you Eric for your reply.
> 
> My problem with preallocation is that i don't know the size of my
> final tar archive. So i would prefer to don't make any supposition.
> 
> Yes, i write a stream of 640x480x1 pnm images (307215 bytes each) to
> a single tar file. So lets say that each write is 307712 (divisible
> by 512 bytes for tar).
> 
> Here is a test bench program that reproduce the behaviour of the real
> app.
> 
> The program log some write overhead at 645579776bytes and other at
> 645887488bytes, so not exactly the same thing as in the real app.
> 
> You will be able to tell me if my test bench is correct (metric,
> compilation options, etc.).

I changed the test for an abnormally long write to printf if the
current time is more than twice the average; the hardcoded time
didn't trip on my run (faster disk?)

uninit_bg

size  480338432 time 10170277 avg 1533119
size  661580800 time  6651861 avg 1559238
size 1025296384 time 16295994 avg 1585389
size 1206538752 time  5157166 avg 1591501
size 1388704256 time 10096621 avg 1596869
size 1570562048 time  6523130 avg 1600365
size 1752727552 time 11047298 avg 1603791
size 1935200768 time  7421506 avg 1606132
size 1963202560 time 13636110 avg 1608181
size 2116750848 time  4634594 avg 1609417
size 2299224064 time 17226228 avg 1612249
diff min : 1468219
diff moy : 1612779
diff max : 17226228
8035 iterations

^uninit_bg

size  125854208 time 11192339 avg 1531071
size  480646144 time  8405476 avg 1537763 *
size  662196224 time  5187685 avg 1562247 *
size  843746304 time 10184477 avg 1577636
size 1025911808 time 15772404 avg 1589258 *
size 1207154176 time  3354220 avg 1594480 *
size 1389011968 time 17024332 avg 1601196 *
size 1570562048 time  5321635 avg 1604032 *
size 1752727552 time 10858699 avg 1607154 *
size 1934585344 time  6316573 avg 1609076 *
size 1963202560 time 12102167 avg 1610854 *
size 1963510272 time  9019437 avg 1612015 *
size 2116135424 time  3464465 avg 1612853 *
size 2297993216 time  8579660 avg 1614396 *
diff min : 1469909
diff moy : 1614416
diff max : 17024332
7493 iterations

* = roughly same offset as with uninit_bg

So uninit_bg doesn't seem to help.  (this was on 2.6.32-ish)

some oprofiling may be in order ...

-Eric

> The system on which i run the test bench has no other workload, no
> other disk access.
> 
> Please find the attached files : - test bench source - the dumpe2fs
> log
> 
> Tonight, i will try with the "-O ^uninit_bg at mkfs time".
> 
> Thanks.
> 
> Paul.
> 
> 
> 

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