Le mardi 06 décembre 2011 05:39:23, NeilBrown a écrit : > Hmm... I cannot reproduce this which makes it harder. Rebooting on a CONFIG_DYNAMIC_DEBUG-enabled kernel and ssh'ing soon enough, I think I found the culprit: noflushd process. (cc'ing its author) <noflushd intro> noflushd is a nice daemon helping suspending disks by tracking disk *read* activity. When enough time has passed without reads, it disables automated flushing (echo 0 > /proc/sys/vm/dirty_writeback_centisecs) and takes over flushing for individual block devices (only flushing spinning devices). This way, there is no extra delay in writes when disk spins, and only an explicit flush (or read) will cause disk to spin up. </noflushd intro> I enabled block_trace to see if the problem was still here, and there was no activity for 10+ seconds. Then I saw traces for noflushd process, and previously-reported writes started ticking every 5s. 5s is the default (at least, on my machine) writeback period, so it's what noflushd uses when taking over per-device flushing. I stopped noflushd process, and tada, problem solved. FWIW, noflushd does individual flushes by opening bock device for write, and fsync()'ing it. Sorry for the noise. Regards, -- Vincent Pelletier -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
