From owner-freebsd-arch Wed Oct 13 17:59:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 167F11513C for ; Wed, 13 Oct 1999 17:59:11 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA29620 for ; Thu, 14 Oct 1999 02:59:10 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA39737 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 02:59:09 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 901B31513C for ; Wed, 13 Oct 1999 17:59:00 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40349>; Thu, 14 Oct 1999 10:54:55 +1000 Content-return: prohibited Date: Thu, 14 Oct 1999 10:58:50 +1000 From: Peter Jeremy Subject: Re: The eventual fate of BLOCK devices. In-reply-to: <199910132344.QAA24624@usr01.primenet.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct14.105455est.40349@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199910131738.KAA18428@flamingo.McKusick.COM> <199910132344.QAA24624@usr01.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-14 09:44:52 +1000, Terry Lambert wrote: >However, this seems to argue for pitching character devices, since >character devices have the restriction that they must be accessed >on block boundaries in block size increments, whereas block devices >have no such restriction. I'd suggest the opposite. Anything that needs to access a physical device needs to know _something_ about the device. Requiring it to understand blocksizes and blocking factors does not seem unreasonable. Providing a stream interface to a naturally block device (eg a raw disk) means that the kernel has to appropriately buffer the data and write it at suitable times. Whilst the kernel knows the blocksize, it cannot know the application behaviour. This means that the performance is likely to be sub-optimal. The other disadvantage is that read/write to a block device implies an extra memory-memory copy, compared to a raw device. (A partially compensating advantage is that mmap(2) may be able to be used instead). >When choosing between interfaces, it seems to me that keeping the >one with the least restrictions, and pitching the one with the most, >would be the more correct approach. You gain the ability to use naive applications with the device. You reduce the ability of `smart' applications to optimise their performance. It's unclear that either approach is clearly better. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message