linux-ext4 - [Bug 20902] High IO wait when writing to ext4

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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