From owner-freebsd-scsi Tue Aug 24 12: 4:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 85E91151F4 for ; Tue, 24 Aug 1999 12:04:25 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id FAA00684; Wed, 25 Aug 1999 05:03:14 +1000 Date: Wed, 25 Aug 1999 05:03:14 +1000 From: Bruce Evans Message-Id: <199908241903.FAA00684@godzilla.zeta.org.au> To: dg@root.com, nick.hibma@jrc.it Subject: Re: The I/O is too slow than linux Cc: freebsd-scsi@FreeBSD.ORG, shift@263.net Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Quite a difference. Linux adapts the blocksize to the read size? Does >>their implementation of dd do something funny? > > As I recall, Linux doesn't have block devices (or is it that it doesn't >have character devices?....hmmm). Linux has only block devices, but for some reason (probably better clustering) they are much faster than ours despite using a smaller block size (1K instad of 2K). I/O is not clustered in any way for FreeBSD block devices, so the throughput is at best the same as for a block size of 2K with the corresponding character device. For IDE devices it is much worse, since the silly DIOCGPART ioctl() is called for every i/o and it does a sillier wait for i/o to complete. This causes amazing slow speeds for newfs on a buffered IDE device (waiting is worse for writes). I've only found one useful class of uses for buffered devices. It is good (*) for un-breaking disk utilities that don't do i/o in blocks, e.g., Linux fsck.ext2. (*) Not actually good for writes, since write errors can not be returned to the application. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message