Quoting Bill Stouder-Studenmund <wrstuden@netbsd.org>:

> So I doubt that the EFS file system on that CD Rom is not going to use any
> block sizes smaller than 2K. So you don't need to read 2K sectors then
> split them up.

Is the 'not' above unintended? EFS definitely does not have variable  
block sizes. It's absolutely fixed at 512 bytes. Further, SGI always  
shipped 512b addressable drives, so far as I'm aware.

In this case, is there any option other than splitting sectors? For  
writable file systems this would probably complicate doing updates in  
a consistent way significantly, but I don't need to worry about that,  
especially when the device block size is not EFS-native (i.e. a cd-rom).

>> Similarly, whatever happened to Koji Imada's work[1] on DEV_BSIZE and
>> Bill Studenmund's related changes[2]? Are these not pertinent to what
>> I'm looking at?
>
> They are pertinent.

[snip]

Thanks for the quick overview. I think I need to read more of Koji's  
posts to better understand what the problem was, and what it intended  
to solve. I had initially assumed it sought to make the buffer cache  
magically provide the desired block size for a consumer, regardless of  
the underlying sector size. Yet I don't immediately see how updates  
could be easily done with consistency in such a scenario.

> We probably need more testing of all of this, but for the most part it
> works according to chs last time I asked (which was a few releases ago).

Shouldn't this all be exercised when we, for example, read a cd9660  
file system?

Steve