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>