3x read to write ratio on dump/restore

M. Warner Losh imp at bsdimp.com
Sat Jan 10 21:05:24 PST 2009

In message: <20090111041710.GB5661 at server.vk2pj.dyndns.org>
            Peter Jeremy <peterjeremy at optushome.com.au> writes:
: On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" <imp at bsdimp.com> wrote:
: >The read kBps was 3x the write kBps.
: ...
: >Any ideas what gives?  I observed this with 16MB cache and with 32MB
: >cache, fwiw.
: I've seen this as well.  AFAIK, this is a side-effect of dump's caching.
: My top-of-head explanation is that each dump process has its own cache
: but actual I/O is round-robined on a (roughly) block scale so a large
: contiguous file will wind up in each 'slave' process's cache.
: The most obvious (and easiest) fixes are to either implement a shared
: cache (though this means another level of inter-process communication)
: or only use a single 'slave' process when caching is enabled.

I'll have to look into this...  Most of the files I was backing up
were large contiguous files (26 10GiB .dv files from my camera).

: The cache algorithm could probably be enhanced as well - apart from
: inode blocks, any block will only be accessed once so once a block has
: been accessed, it can be purged from the cache (which is completely
: opposite to a "normal" cache).

Yes, read everything, purge once it is touched.


More information about the freebsd-hackers mailing list