On 8/9/22 18:28, gwes wrote:
On 8/9/22 13:14, Christian Weisgerber wrote:
Kenneth Gober:
Are you certain that dump(8) is the big bottleneck here? My
recollection
is that restore(8) is significantly slower, so of course if
restore(8) is
systat's default vmstat display shows you the time spend in disk
accesses. Typical figures during the dump-restore run were 1.0 for
the dump disk and 0.0 for the restore disk, i.e., the dump disk was
saturated and the restore disk was practically idle. Also the
number of transfers was a magnitude higher for the dump disk, i.e.,
a larger number of smaller reads compared to a smaller number of
larger writes.
So, yeah, the dump(8) side is the bottleneck.
dump(8) reads the raw device unbuffered and caches relatively little
restore(8) writes the cooked device which tries very hard to minimize
disk accesses and buffers a great deal.
It looks like most of dump(8)'s reads are small(er) than file system
buffers.
The input files may consist of blocks scattered all over which would
cause
seek and rotational delays.
iostat(1) transfer size etc and vmstat syscall count would tell a lot
geoff steckel
Apologies for not reading fully.
