| 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: <20120513044052.GC31866@thunk.org> Date: Sun, 13 May 2012 00:40:52 -0400 From: Ted Ts'o <tytso@....edu> To: Björn Christoph <einkaufenbc09@...glemail.com> Cc: linux-kernel@...r.kernel.org Subject: Re: BUG: jbd2 slowing down file copies even though no journaling file system is used On Sun, May 13, 2012 at 01:21:00AM +0200, Björn Christoph wrote: > > IOTOP shows this in some cases, mostly jbd2 is not there: > PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND > 416 be/3 root 0.00 B/s 97.65 M/s 0.00 % 13.74 % [jbd2/dm-1-8] Well, the file system in that has the huge write bandwidth is whichever device is associated with device mapper device dm-1 (i.e., with a device mapper minor number of 1). What does "ls -l /dev/mapper" show you? Whatever file system is associated with it is clearly generating a lot of journal activity. Something that may help in determining what process is generating all of this journal activity (which is likely the result of something calling fsync a lot) is to try this: echo 1 > /sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable ... then wait for a minute or so, and then capture the output of: cat /sys/kernel/debug/tracing/trace See if that shows up anything useful. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists