> > But it has to go somewhere, and 2.4 right now is unusable on two of my boxes
> > with M/O drives.
>
> Reads can be pretty easily padded, but writes are a bit harder. Maybe
> push it to some helper before the device queue sees it? For 2.4 the
> best sd solution is probably to just make it
On Mon, Feb 19 2001, Alan Cox wrote:
> > 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
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> > Strange. The twelve or so CD readers I have here are all
> > able to read 512-byte sectors. I am quite willing to believe
>
> I think most Plextor and Yamaha do, but it's not guaranteed to
> be supported. And it definitely won't
> 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
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> > 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
> 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
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;
>
From: Jon Forsberg <[EMAIL PROTECTED]>
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't
I have two ext2 CD-ROMs. One of them I can mount the normal way, the other I
can't. Both are ok according to debugfs and e2fsck and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom' instead, both works.
The one that doesn't work have a blocksize of 1024 according to debugfs:
Block size = 1024,
I have two ext2 CD-ROMs. One of them I can mount the normal way, the other I
can't. Both are ok according to debugfs and e2fsck and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom' instead, both works.
The one that doesn't work have a blocksize of 1024 according to debugfs:
Block size = 1024,
From: Jon Forsberg [EMAIL PROTECTED]
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't
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;
}
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
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
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
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
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
Strange. The twelve or so CD readers I have here are all
able to read 512-byte sectors. I am quite willing to believe
I think most Plextor and Yamaha do, but it's not guaranteed to
be supported. And it definitely won't for
On Mon, Feb 19 2001, Alan Cox wrote:
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
But it has to go somewhere, and 2.4 right now is unusable on two of my boxes
with M/O drives.
Reads can be pretty easily padded, but writes are a bit harder. Maybe
push it to some helper before the device queue sees it? For 2.4 the
best sd solution is probably to just make it able to
18 matches
Mail list logo
