3x read to write ratio on dump/restore

[Yoshihiro Ota]

Jermey, I tought you wrote this,
http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html.


Try GEOM Cache(gcache).

It will be like,

$ gcache create temp -s <size> /dev/XXYsZ
$ dump <options> /dev/cache/temp <...>

It's been 9 months since I tested so I don't remember about the detail numbers.
However, I think it reduced user-time with dump to a half.

I only wish gcache creates devices with .cache suffix like /dev/XXYsZ.cache.
The cache cannot be shared among other providers anyway,
it looks suffix style is more appropriate.

Regards,
Hiro

On Sun, 11 Jan 2009 15:17:10 +1100
Peter Jeremy <peterjeremy at optushome.com.au> wrote:

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