[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: dump(8) performance
From:       "Greg 'groggy' Lehey" <grog () freebsd ! org>
Date:       2006-05-31 23:54:57
Message-ID: 20060531234835.GW54613 () wantadilla ! lemis ! com
[Download RAW message or body]


On Wednesday, 31 May 2006 at  8:05:21 -0700, Eugene M. Kim wrote:
> While watching the output of iostat -dxz -w10 -n100 to monitor the
> progress/performance of a dump(8) process straight to a tape, I found
> out something interesting and disappointing at the same time: The disk
> read throughput was exactly twice as high as the tape write throughput,
> throughout the entire dump phases 4 and 5, i.e. dumping actual inodes.
> Disappointing, because the tape drive utilization (%busy) was lingering
> around 35%-50% for most of the time; I didn't expect the disk would be
> the bottleneck. :p
>
> I want to believe that this indicates a bug in dump(8) which causes each
> disk block to be read twice, but being no UFS expert in any sense, I
> wonder: Could this behavior be by design, and would there be any room
> for improvement?

Without looking at the code, this seems unlikely.  But you might get
more information by attaching a ktrace to the dump process for a short
period of time (find the pid, then ktrace -p<pid> to start trace,
ktrace -p<pid> -C to stop again).  If you do that, let me see no more
than 30 lines of repetitive trace.

Greg
--
See complete headers for address and phone numbers.

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]