Re: dump(8) is slow

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.