3x read to write ratio on dump/restore

[Peter Jeremy]

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.

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).

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090111/c5457fe8/attachment.pgp