| 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: <201011240513.oAO5DMoG002507@demeter1.kernel.org> Date: Wed, 24 Nov 2010 05:13:22 GMT From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...r.kernel.org Subject: [Bug 20902] High IO wait when writing to ext4 https://bugzilla.kernel.org/show_bug.cgi?id=20902 --- Comment #17 from Eric Sandeen <sandeen@...hat.com> 2010-11-24 05:13:16 --- Created an attachment (id=38012) --> (https://bugzilla.kernel.org/attachment.cgi?id=38012) graph of IO Here's a graph of the IO. Does the trace cover the entire test starting at mount? Looks like it. Were the 10x128MB writes in series or parallel? Looks like it spends about 20s seekily sucking up 28MB of metadata off the disk (mostly done in the [flush-253:0] process) and then doing 1.3G of horrible writeback ;) What exact commands did you use for the test; I assume it was buffered IO, all in the same subdir? Sync afterwards or not? It might be interesting to see the tune2fs -l output to correlate the initial reads to disk metadata but I suppose we can have a pretty good guess at that. Anyway looks like the first issue is the giant seeky read of disk metadata before any writing even gets underway. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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