Date: Tue, 2 Nov 1999 18:51:46 -0500 From: Greg Lehey <grog@mojave.sitaranetworks.com> To: Zhihui Zhang <zzhang@cs.binghamton.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: Granularity of disk I/O Message-ID: <19991102185146.61123@mojave.sitaranetworks.com> In-Reply-To: <Pine.GSO.3.96.991102165830.16585A-100000@sol.cs.binghamton.edu>; from Zhihui Zhang on Tue, Nov 02, 1999 at 05:10:41PM -0500 References: <Pine.GSO.3.96.991102165830.16585A-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991102185146.61123>