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
| ||
|
Message-ID: <20120813213547.GH32484@thunk.org> Date: Mon, 13 Aug 2012 17:35:47 -0400 From: Theodore Ts'o <tytso@....edu> To: Zach Brown <zab@...hat.com> Cc: Andreas Dilger <adilger@...ger.ca>, Zheng Liu <wenqing.lz@...bao.com>, Eric Sandeen <sandeen@...hat.com>, Zheng Liu <gnehzuil.liu@...il.com>, ext4 development <linux-ext4@...r.kernel.org> Subject: Re: [PATCH v2] ext4: dynamical adjust the length of zero-out chunk On Mon, Aug 13, 2012 at 12:49:02PM -0700, Zach Brown wrote: > > Indeed. fio to the rescue. > > I remember Christoph saying something about 64k somewhat recently? But, > helpfully, I can't recall the details :). So here are some quick fio numbers, using a modern 5400rpm 2.5" disk, using 8192 samples doing random writes at different sizes: 4k min=0.099 , max=69.980 , avg=1.95249 8k min=0.112 , max=71.393 , avg=2.39577 16k min=0.123 , max=79.951 , avg=3.29693 32k min=0.190 , max=75.846 , avg=3.57158 64k min=0.305 , max=71.386 , avg=4.43218 128k min=0.554 , max=77.925 , avg=6.40304 256k min=1 , max=68 , avg=10.21 If we take into account that a random write into a fallocate'd file will need to update the extent tree, this is the time that it would take to do a 4k random write if we are also using a more aggressive max zero-out length (plus the extent tree block update): zerooout + 4k metadata update (ms) 4k 3.90 8k 4.35 16k 5.25 32k 5.52 64k 6.38 128k 8.36 256k 12.16 So I can see going to 64k, but unless we're really concerned about extent fragmentation, I don't think larger values make a whole lot of sense, especially if we are concerned about lowering latency variability when writing into freshly fallocate'd space. And if the concern is extent fragmentation, we may be better off fixing our extent tree manipulation code so we are better at merging adjacent extent tree blocks instead. - 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
Powered by blists - more mailing lists