Date: Wed, 27 Aug 1997 11:16:33 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: dg@root.com Cc: current@FreeBSD.ORG Subject: Re: IDE vs SCSI was: flags 80ff work... Message-ID: <XFMail.970827111633.Shimon@i-Connect.Net> In-Reply-To: <199708270258.TAA19831@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi David Greenman; On 27-Aug-97 you wrote:
> FreeBSD can read and write up to 64KB, depending on various factors
> including the contiguousness of the file, the sequentialness of the
> accesses,
> and other factors. Random reads/writes to a file will usually happen in
> blocksize chunks which are either 4KB or (more commonly) 8KB.
I did some homework:
Ran some tests on two systems:
Both systems are P6-200 SMP, running as UP.
Sendero is running 3.0-Current as of tonight.
Copper is Running 2.2 as of tonight
This is NOT a performance test. The timing numbers are just for
completeness. Min and Max are in microseconds.
Both systems were booted to multi-user, and a sample taken.
Sendero then was put into a typical load which included compiling
about 10 different kernels, email, etc.
Copper was left alone, except for running:
``dd if=/dev/sd16s1a of=/dev/null bs=1024k''
The partition read is a 6GB slice off a 6x4GB RAID-0 array
Interesting points to ponder (suggested reading :-):
David is absolutely correct in assessing the file system usage.
I was totally wrong on that one and went back to my notes:
While David is right in regards to the filesystem, I did get
something correctly. Regardless of block size specified, access
to a block device is always in 4K blocks. Access to the raw (char)
device will be in the specified units, rounded to 512 bytes, but
no more than 64K at a time.
My foggy memory that O/Ss in general are better at READ caching
than at WRITE caching is probably correct. Compiling a kernel
should have about an even mix of READ/WRITE. What ends up in the
disk is about 1:25. Look at the 8K read and write on Sendero.
Several things come out of this:
* Caching controllers do make sense.
* Stripe size much in excess of 8K is wasteful (or should be).
* RAID-5 is probably NOT what you want for compile intensive
filesystems. I would say RAID-0 (as source can be re-CVSed
and object re-compiled. If reliability these is essential,
use RAID-1.
* Anyone cares to guess what the ``Other'' block size is?
On UnixWare (at one point or another) it turned out to be
3K. The missing 3/4 page from a filesystem inode read.
1. Sendero:
------ Just booted ------- --- After Load --- Net
Blk Count Min Max Count Min Max
Read 512 41 258 46022 41 258 46022 0
1K 222 267 1018265 1185 259 1018265 963
2K 49 374 1018061 278 337 1018061 229
4K 49 1312 39506 2940 355 1009199 2891
8K 494 519 1017799 3412 517 1047893 2918
16K 85 1431 1008056 346 843 1019672 261
32K 58 2399 1010198 286 2034 1012978 228
64K 0 0 0 114 3269 99489 114
Larger 0 0 0 0 0 0 0
Other 182 1036 1020875 3838 388 1025511 3656
Write 512 0 0 0 0 0 0 0
1K 219 267 47588 4626 228 1047802 4407
2K 202 319 47256 1761 319 1066111 1559
4K 16 436 25355 1232 417 1039338 1216
8K 1498 624 1000692 77371 578 1142455 75873
16K 33 1103 3864 473 1103 1067547 440
32K 2 2403 2588 254 2372 1043489 252
64K 6 4396 5499 1321 4394 1248494 1315
Larger 0 0 0 0 0 0 0
Other 84 380 38171 18566 380 1072166 18482
3. Copper just after booting
----- Just booted ------ ------ After Dd ------ Net
Size Count Min Max Count Min Max
Read 512 53 264 1022266 63 264 1022266 10
1K 11901 251 1013350 11918 251 1013350 17
2K 110 357 1018538 116 357 1018538 6
4K 34 503 22751 1572901 330 1038746 1572867 <-!!
8K 1090 518 1024360 1105 518 1024360 15
16K 56 831 1018888 60 831 1018888 4
32K 46 3674 28092 50 3674 37735 4
64K 1 13607 13607 1 13607 13607 0
Larger 0 0 0 0 0 0 0
Other 5765 437 1046068 5774 437 1046068 9
Write 512 0 0 0 0 0 0 0
1K 102 276 44721 125 276 44721 23
2K 61 341 44950 71 341 44950 10
4K 5 3079 15590 5 3079 15590 0
8K 443 695 1060177 721 695 1060177 278
16K 2 32957 35854 2 32957 35854 0
32K 2 2441 6630 2 2441 6630 0
64K 2 4650 11308 2 4650 11308 0
Larger 0 0 0 0 0 0 0
Other 31 684 1060570 44 684 1060570 13
Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970827111633.Shimon>