From owner-freebsd-current Wed Aug 27 18:37:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA28073 for current-outgoing; Wed, 27 Aug 1997 18:37:07 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA28055 for ; Wed, 27 Aug 1997 18:37:02 -0700 (PDT) Received: (qmail 2123 invoked by uid 1000); 28 Aug 1997 01:37:16 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199708271936.FAA05649@godzilla.zeta.org.au> Date: Wed, 27 Aug 1997 18:37:16 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Bruce Evans Subject: Re: IDE vs SCSI was: flags 80ff work... Cc: current@freebsd.org, dg@root.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Bruce Evans; On 27-Aug-97 you wrote: > >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 > >... > >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. > > Nope. By default, block devices are accessed with the too-small > block size of BLKDEV_IOSIZE = 2K. The default is used for the > whole-disk device (e.g., /dev/sd16) unless the disk is "dedicated" > and happens to have a BSD file system on its "c" partition. > For block devices that have a BSD file system on them, the block > size is taken from the file system. You apparently have a BSD > file system with a block size of 4K on /dev/sd16s1a. 4K is a > small block size for a BSD file system (the default is 8K and > the max is 64K), but is good for some applications (ones where > the average write is <= 4K, and ones where disk space is scarce). I have no filesystem of any kind on that partition. I have seen it before. I trust that what you describe should be correct, but in practive, you may not be. I offered this as an explanation of what caused me to make a mistake, and now you tell me I am yet wrong again :-) > Block devices are unsuitable for almost everything except mounting > file systems on. They are unsuitable for benchmarks because you > can't control the block size. They make for a very interesting database storage device. Write to the bdev and you get buffered I/O. Write to the cvdev and you get unbuffered, uncached I/O. > I just noticed another bug: stat() says that st_blksize is 2K > for all bdevs. It doesn't know that a different size is used > internally for bdevs with a BSD file system on them. (st_blksize > is bogus for cdevs too. It is always MAXBSIZE = 64K, which is > excessive for terminals. This problem got worse when MAXBSIZE > was increased from 16K to 64K.) Stat also never tells you the size of a cdev, only of a bdev. Simon