Date: Thu, 28 Aug 1997 05:36:47 +1000 From: Bruce Evans <bde@zeta.org.au> To: dg@root.com, Shimon@i-Connect.Net Cc: current@freebsd.org Subject: Re: IDE vs SCSI was: flags 80ff work... Message-ID: <199708271936.FAA05649@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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). 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. 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.) Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708271936.FAA05649>