Date: Thu, 14 Oct 1999 10:58:50 +1000 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. Message-ID: <99Oct14.105455est.40349@border.alcanet.com.au> In-Reply-To: <199910132344.QAA24624@usr01.primenet.com> References: <199910131738.KAA18428@flamingo.McKusick.COM> <199910132344.QAA24624@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Oct14.105455est.40349>