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

Jens Axboe (axboe@suse.de)
Sun, 18 Feb 2001 20:16:39 +0100


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

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/