Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM

[Jens Axboe <axboe@suse.de>]

On Sun, Feb 18 2001, Andries.Brouwer@cwi.nl wrote:
> Someone has added
>         /*
>          * These are good guesses for the time being.
>          */
>         for (i = 0; i < sr_template.dev_max; i++) {
>                 sr_blocksizes[i] = 2048;
>                 sr_hardsizes[i] = 2048;
>         }
>         blksize_size[MAJOR_NR] = sr_blocksizes;
>         hardsect_size[MAJOR_NR] = sr_hardsizes;
> setting of hardsect_size to drivers/scsi/sr.c.
> 
> A value of hardsect_size[] means: this is the smallest size
> the hardware can work with. It is therefore a serious mistake
> just to come with "a good guess". This value is used only

You are defeating the entire purpose of having a hardware sector
size independently from the software block size. And 2kB is a
valid guess, apart from the drives that do 512 byte transfers too
2kB is really the smallest transfer we can do.

> to reject impossible sizes, and everywhere the kernel accepts 0
> meaning "don't know".

So put 0 and sure anyone can submit I/O on the size that they want.
Now the driver has to support padding reads, or gathering data to do
a complete block write. This is silly. Sr should support 512b transfers
just fine, but only because I added the necessary _hacks_ to support
it. sd doesn't right now for instance.

In my oppinion we are always going to have hacks like this unless we
add some generic support for < hardware submission of I/O. Simply
ignoring this issue only makes it worse.

-- 
Jens Axboe