Date: Thu, 1 May 1997 19:31:20 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) To: freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG Cc: dan@math.berkeley.edu Subject: Re: cvs commit: src/sys/scsi sd.c Message-ID: <199705020231.TAA24685@math.berkeley.edu>
next in thread | raw e-mail | index | archive | help
> 1) What should sd and other devices drivers "see" by the time they receive > the I/O? Should b_blkno always be in terms of the logical block size of > the device or should the device driver be responsible for scaling? > ... There are really two different problems here. One is how we communicate the device address to the device driver and the other is what we do if the requested I/O operation does not begin and end at block boundaries. The main limitations of the current convention, passing a bock number in b_blkno, is that it forces applications using the device to know what the block size is and it does not allow specification of an arbitrary byte address. The most straight forward fix is to change the block number to a byte number, but this would force significant change in other parts of the OS and there may be some value in having the OS know something about device block sizes. Therefore I recommend adding a b_bytoff field to the buffer structure and a device block size field to some appropriate per device structure. The block size would default to 512 bytes so that existing code wouldn't need to be changed. Byte addressed devices could use a block size of 1 and ignore the byte offset. Since the OS would know the block size, it could be extended to provide more general data blocking services (e.g. a generalized physio routine that knows how to read or modify just a part of a physical device block). Programs could exchange block size information with each other and the kernel in a general way and the device address could be made to mean something for tapes operating in a variable record size mode. In practice, nearly all disk applications will like block sizes that are a power of two, so special code might be written to optimize for that specific situation but the general case should be implemented anyway. It only takes a little extra code and that code won't be used unless it is needed. (Hint: a buffer size is a power of two iff (size-1)^size == 0.) Several years ago I did something like this for a SunOS SCSI disk driver and was quite pleased with the results. The OS would seldom do I/O not aligned on a file system block boundary (8kb) and consequently there was essentially no performance problem (and CR-ROMS with a 2K block size worked!). Dan Strick dan@math.berkeley.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705020231.TAA24685>