Apparent strange disk behaviour in 6.0
Poul-Henning Kamp
phk at phk.freebsd.dk
Sat Jul 30 10:33:58 GMT 2005
In message <42EB5687.2070400 at elischer.org>, Julian Elischer writes:
>Poul-Henning Kamp wrote:
>> In message <42E88135.30603 at elischer.org>, Julian Elischer writes:
>>
>> Please use gstat and look at the service times instead of the
>> busy percentage.
>
>The snapshot below is typical when doing tar from one drive to another..
>(tar c -C /disk1 f- .|tar x -C /disk2 -f - )
>
>dT: 1.052 flag_I 1000000us sizeof 240 i -1
> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
> 0 405 405 1057 0.2 0 0 0.0 0 0 0.0 9.8 | ad0
> 0 405 405 1057 0.3 0 0 0.0 0 0 0.0 11.0 | ad0s2
> 0 866 3 46 0.4 863 8459 0.7 0 0 0.0 63.8 | da0
> 25 866 3 46 0.5 863 8459 0.8 0 0 0.0 66.1 | da0s1
> 0 405 405 1057 0.3 0 0 0.0 0 0 0.0 12.1 | ad0s2f
> 195 866 3 46 0.5 863 8459 0.8 0 0 0.0 68.1 | da0s1d
>
>even though the process should be disk limitted neither of the disks is anywhere
>near 100%.
This looks like an awful lot of small files since you write 8 times as much data
as you read ?
Since the write service time (ms/w) is low, I pressume you have
some hefty disk hardware (with cache ?)
Presumably you're using softupdates ?
I wouldn't be surprised if you were limited by system time rather than disk in
this scenario ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-current
mailing list