Re: 3x read to write ratio on dump/restore
On 2009-Jan-12 05:05:37 -0500, Yoshihiro Ota o...@j.email.ne.jp wrote: Jermey, I tought you wrote this, http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html. Yes, that is my message. I had forgotten it. If you dig back further, you'll find that I looked into the poor read behaviour of dump before the caching code existed (and one of the outcomes of that thread was the current caching code). -- 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. pgpnsWptLOPL6.pgp Description: PGP signature
Re: 3x read to write ratio on dump/restore
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 peterjer...@optushome.com.au wrote: On 2009-Jan-09 09:50:27 -0700, M. Warner Losh i...@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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
gcache [was: Re: 3x read to write ratio on dump/restore]
Yoshihiro Ota schrieb: Try GEOM Cache(gcache). Just a side note: gcache does not seem to have any documentation. man gcache is unsuccessful, geom(8) does not mention it (geom and gcache are the same hardlinked binary). Is there information about it somewhere? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 3x read to write ratio on dump/restore
According to M. Warner Losh: The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. dump launches several processes to read the raw device and use a buffer between them whereas restore is single process. When copying from disk to disk, I often use team (sysutils/team) to stream. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcache [was: Re: 3x read to write ratio on dump/restore]
Christoph Mallon wrote: Yoshihiro Ota schrieb: Try GEOM Cache(gcache). Just a side note: gcache does not seem to have any documentation. man gcache is unsuccessful, geom(8) does not mention it (geom and gcache are the same hardlinked binary). Is there information about it somewhere? AFAIK it's very experimental, might not be there in this form in the future. signature.asc Description: OpenPGP digital signature
Re: gcache [was: Re: 3x read to write ratio on dump/restore]
On Mon, Jan 12, 2009 at 11:41:11AM +0100, Christoph Mallon wrote: Yoshihiro Ota schrieb: Try GEOM Cache(gcache). Just a side note: gcache does not seem to have any documentation. man gcache is unsuccessful, geom(8) does not mention it (geom and gcache are the same hardlinked binary). Is there information about it somewhere? ___ A manpage for gcache is currently under review. Hopefully it will be committed in the next couple of days. - Christian -- Christian Brueffer ch...@unixpages.org bruef...@freebsd.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpCgQbu0zxJZ.pgp Description: PGP signature
Re: gcache [was: Re: 3x read to write ratio on dump/restore]
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Christian Brueffer wrote: | On Mon, Jan 12, 2009 at 11:41:11AM +0100, Christoph Mallon wrote: | Yoshihiro Ota schrieb: | Try GEOM Cache(gcache). | Just a side note: gcache does not seem to have any documentation. man | gcache is unsuccessful, geom(8) does not mention it (geom and gcache | are the same hardlinked binary). Is there information about it somewhere? | ___ | | A manpage for gcache is currently under review. Hopefully it will be | committed in the next couple of days. Unfortunate name clash with apache13-ssl's gcache though. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAklrN/0ACgkQ8Mjk52CukIxRcwCfQYWp6FHjrsFn0u3MBofWlhNg mhgAnRz2zNyW4WSe8W8Lc+0XK49LVPud =trWs -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcache [was: Re: 3x read to write ratio on dump/restore]
On Mon, 12 Jan 2009 11:41:11 +0100 Christoph Mallon christoph.mal...@gmx.de wrote: Yoshihiro Ota schrieb: Try GEOM Cache(gcache). Just a side note: gcache does not seem to have any documentation. man gcache is unsuccessful, geom(8) does not mention it (geom and gcache are the same hardlinked binary). Is there information about it somewhere? The CVS log was the best document available I took a look back in one year ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/cache/g_cache.h?rev=1.1 About the link, it is also true for many other providors, too. That is based on how GEOM library were implemented and so on. % ls -i /sbin/g* 590 /sbin/gbde 495 /sbin/ggatel520 /sbin/gpt 592 /sbin/gcache592 /sbin/gjournal 592 /sbin/graid3 592 /sbin/gconcat 592 /sbin/glabel524 /sbin/growfs 592 /sbin/geli 592 /sbin/gmirror 592 /sbin/gshsec 592 /sbin/geom 592 /sbin/gmultipath592 /sbin/gstripe 258 /sbin/ggatec592 /sbin/gnop 528 /sbin/gvinum 440 /sbin/ggated592 /sbin/gpart 592 /sbin/gvirstor Hiro ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 3x read to write ratio on dump/restore
In message: 20090111041710.gb5...@server.vk2pj.dyndns.org Peter Jeremy peterjer...@optushome.com.au writes: : On 2009-Jan-09 09:50:27 -0700, M. Warner Losh i...@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. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
3x read to write ratio on dump/restore
I just copied a disk using dump + restore. I noticed something through the whole run of this 500GB operation: L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 3231231 147549.5 0 00.0 97.5| da1s1a 0 39 0 00.0 39 4982 10.0 38.7| da2s1a The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. Any ideas what gives? I observed this with 16MB cache and with 32MB cache, fwiw. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 3x read to write ratio on dump/restore
Hi Warner, On Friday 09 January 2009 17:50:27 M. Warner Losh wrote: I just copied a disk using dump + restore. I noticed something through the whole run of this 500GB operation: L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 3231231 147549.5 0 00.0 97.5| da1s1a 0 39 0 00.0 39 4982 10.0 38.7| da2s1a The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. Any ideas what gives? I observed this with 16MB cache and with 32MB cache, fwiw. I've noticed this too. Last week I upgraded a laptop harddisk and used dump + restore to copy files from the original harddisk (attached to the laptop using a USB bracket). During the entire copy process I also saw about a 3x difference. -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
