On Sun, Feb 18 2001, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
