On Fri, 3 Apr 2009, Linus Torvalds wrote: > > The "overwrite" behavior may well be better, but it was smooth enough > beforehand too (never having more than ~8MB dirty). The "create big file > and sync" workload causes huge fsync pauses, though. IOW, try with > > while : > do > time sh -c "dd if=/dev/zero of=bigfile bs=8M count=256 ; sync" > done > > and even really small fsync's end up being at the end of all that > unrelated activity, and you see things like > > fsync(7) = 0 <32.756308> Hmm. So I decided to try with "data=writeback" to see if it really makes that big of a difference. It does help, but I still easily trigger multi-second pauses: fsync(4) = 0 <2.447926> fsync(4) = 0 <4.275472> fsync(4) = 0 <3.731948> fsync(4) = 0 <4.020839> fsync(6) = 0 <3.482735> fsync(6) = 0 <5.819923> even though the system _should_ be able to write back the 'bigfile' datablocks without any ordering constraint on the fsync. So at a guess, it now avoids some nasty journal writing ordering issue where it has to wait for the previous transaction, and it's probably now purely an IO ordering issue. This is all with your ext3 work, btw. But I also added "rm bigfile" at the end of the loop (so that it shouldn't trigge any "write out bigfile early" logic), and that didn't seem to make any difference. Are we perhaps ending up doing those regular 'bigfile' writes as WRITE_SYNC, just because of the global "sync()" call? That's probably a bad idea. A "sync" is about pure throughput. It's not about latency like "fsync()" is. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
