User: Password:
Subscribe / Log in / New account

In defense of per-BDI writeback

In defense of per-BDI writeback

Posted Oct 3, 2009 15:00 UTC (Sat) by anton (subscriber, #25547)
Parent article: In defense of per-BDI writeback

The fundamental problem with pdflush is that it would back off when the backing device appeared to be congested.
That might explain the huge slowdowns I saw (on Linux 2.6.19 and 2.6.27) when writing several GB to flash devices. One was a pretty fast 8GB SD card (SDHC class 6 (i.e., >6MB/s on a certain workload), and I typically saw >10MB/s when writing several hundred MB), yet it took several hours to fill up; I no longer remember if the system also suffered in other ways. Calling sync now and then seemed to help, but the whole thing still took a very long time.

I do not think that the problem was in the flash device, because it was originally new (no need to shuffle old data around), the slowdown occured pretty soon (not only near the end), and various measures taken at the host end helped (like invoking sync, or writing the data in smaller batches which syncing in between).

I had a similar experience when trying to fill my 8GB ogg player with music, except that this device was slow to begin with (3MB/s when writing a few hundred MB), but filling it up still should not have taken 8 hours (280KB/s).

(Log in to post comments)

In defense of per-BDI writeback

Posted Oct 11, 2009 6:30 UTC (Sun) by mfedyk (guest, #55303) [Link]

I was doing a similar test, but over network filesystems (cifs in this case -- centos5 on both sides).

If I copied files with cp or mv, I noticed a marked improvement in throughput compared to the gnome file manager.

Try it again with mv or cp and see if there is a difference.

In defense of per-BDI writeback

Posted Oct 11, 2009 12:59 UTC (Sun) by anton (subscriber, #25547) [Link]

I did use cp.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds