linux-ext4 - [Bug 14830] When other IO is running sync times go to 10 to 20 minutes

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: <201001191938.o0JJcac7009370@demeter.kernel.org>
Date:	Tue, 19 Jan 2010 19:38:36 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

Theodore Tso <tytso@....edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #5 from Theodore Tso <tytso@....edu>  2010-01-19 19:38:34 ---
So the Linux write cache mystery is unlikely to solve the problem since that
was talking about backporting some tuning parameters from 2.6.22 to the
RHEL/CentOS 2.6.18 kernel, and here the problem seems to be that the sync is
taking much longer on a 2.6.31 FC 12 kernel. 

So the first thing I notice is the fact that you have the nodelalloc mount
option enabled.   Any particular reason why you did that?   Try removing that;
one of the reasons why ext4 is generally described as being much better than
ext3 with respect to this problem (of the machine becoming unresponsive during
a sync) is because of delayed allocation, and you've turned it off.   So try
removing nodelalloc and see if that makes the performance come back.

Another thing that might be worth testing is to see whether an ext3 filesystem
on a 2.6.31 FC 12 kernel behaves any differently.   This may be something that
is some kind of VM tuning issue between RHEL 5.4 and a modern kernel; I don't
know how many people try running Fedora 12 on a system with large amounts of
memory and an NFS load, and maybe there is some kind of tuning issue that has
been exposed.   So that's a quick experiment that's worth doing just so we can
figure out where we need to concentrate our diagnostic efforts.

Another thing to try is to do some instrumentation using iostat to see what the
system is doing, before, during, and after the sync command.

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