From owner-freebsd-hackers Wed Nov 3 9:32:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 9B1101553C for ; Wed, 3 Nov 1999 09:32:43 -0800 (PST) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id MAA00205; Wed, 3 Nov 1999 12:32:20 -0500 (EST) Date: Wed, 3 Nov 1999 11:29:11 -0500 (EST) From: Zhihui Zhang Reply-To: Zhihui Zhang To: Greg Lehey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Granularity of disk I/O In-Reply-To: <19991102185146.61123@mojave.sitaranetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 2 Nov 1999, Greg Lehey wrote: > 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. > Thanks for your reply. I know that directory entries are physically prevented from crossing device block boundaries in order to ensure atomic update. If I write a directory file with a buffer (using some kind of multi-sector transfer) and do not know which sector within the buffer fails, what will the filesystem do? -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message