| 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
| ||
|
Date: Mon, 25 Jan 2010 08:27:31 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 --- Comment #8 from Theodore Tso <tytso@....edu> 2010-01-25 08:27:26 --- Hmm, can you run "iostat 1 | tee iostat.log &", and while that is running, wait for a 15 seconds or so we can capture what things like in steady state, and then type "sync", and note when the sync command was initiated in the iostat.log file? It would be useful seeing what this looks like on both your ext3 production server and on the ext4 test server. Do you know if there are any other differences between the two systems, in terms of the workload seen by your production server versus your test server? Another thing that would be very useful to do is to enable ftrace, and then cd to /sys/kernel/debug/tracing. (This assumes that you have debugfs mounted on /sys/kernel/debug.) Then "echo 1 > events/jbd2/jbd2_run_stats/enable" and then in a similar fashion, do "cat trace_pipe | tee /tmp/trace.output", wait for four or five data samples from your file system of interest, and then issue the sync command, and let's see what is happening. -- 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