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>] [day] [month] [year] [list]
Message-Id: <201001182150.o0ILoeoi027264@demeter.kernel.org>
Date:	Mon, 18 Jan 2010 21:50:40 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14830] When other IO is running sync times go to 10 to 20
 minutes

http://bugzilla.kernel.org/show_bug.cgi?id=14830


Jan Kara <jack@...e.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jack@...e.cz




--- Comment #2 from Jan Kara <jack@...e.cz>  2010-01-18 21:50:38 ---
There are two issues here - the first is that sync takes long - this is at the
level of "don't do it when it hurts" kind of thing ;). So when you do heavy
writing and call sync, it simply takes long time to flush all the caches to
disk. If you think the time is inappropriately long, we can have a look at it
but for that we'd need much more details like amount and nature of data writen
(many small files vs a few large ones), time it takes sync to complete, speed
of disks for sequential IO...

The second issue is that nfsd blocks as well. Partly this might be because sync
blocks writers (so that it can get it's work done in a finite time), partly it
might be a limitation of ext4 because all metadata writes go through a journal
which has a limited size and thus we have to copy data from the journal to
final locations on disk once in a while and that usually leads to all writer
processes blocking waiting for the journal space to be freed (which can take a
longer time when 'sync' process is making disk busy with data writes).

Note in the log file:
This problem prevents production use of systems using this kernel.

evokes a question: Do you have a kernel which behaved better for you? Which
one?

-- 
Configure bugmail: http://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

Powered by Openwall GNU/*/Linux Powered by OpenVZ