From owner-freebsd-hackers Tue Nov 2 15:52:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id 2D82414E3E for ; Tue, 2 Nov 1999 15:52:22 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991102185146.61123@mojave.sitaranetworks.com> Date: Tue, 2 Nov 1999 18:51:46 -0500 From: Greg Lehey To: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG Subject: Re: Granularity of disk I/O Reply-To: Greg Lehey References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Zhihui Zhang on Tue, Nov 02, 1999 at 05:10:41PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 2 November 1999 at 17:10:41 -0500, Zhihui Zhang wrote: > > It is said that the granularity of disk I/O is a sector. I read a little > bit of the source code isa/wd.c, which I think is the driver of IDE disks. > I find out that the disk can perform multi-block I/O sometimes. Does this > mean the granularity of disk I/O can be multi-sector? I think you're getting bogged down in terminology. I understand "granularity" to imply the steps in which a quantity can be increased. In this case, a disk transfer is a whole number of sectors between 1 and 256 (though there's an artificial limit which makes it difficult to transfer more than 60 at a time). Using my definition, it would be correct to say that the granularity is 1 sector. > If the disk can perform DMA, what is the usual DMA size? It's normally the size of the transfer, but in the case of IDE drives it can be limited to a maximum value by the the disk flags. > If a buffer cache is larger than one sector, it should be split into > sectors before I/O. No, that would give lousy performance. Buffer cache is also allocated in blocks corresponding to the transfer size. > If an I/O on a buffer fails, can we tell which sector within that > buffer fails? I don't think we do that. The way to recover would be to retry the I/O a sector at a time. That way, you waste time in the exceptional case only. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message