Re: dump(8) is slow

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