2048 byte/sector problems with kernel 2.4

2048 byte/sector problems with kernel 2.4

[Jurgen Kramer]

Hi,

I recently acquired a 1.3GB MO drive. When I use small (230MB and 540MB)

MO disks which have normal 512 bytes/sector it all works flawlessly but
as soon
as a put in a 1.3GB disk which uses the 2048 bytes/sector format it all
goes
wrong. As soon as I write something to the disk by issuing a cp command
the command
just eats 99% CPU time and does not write a single byte to disk (it
seems). Is this a
known problem? When I check the kernel logs it seems that the sector
size is correctly
identified. The problems occurs with both the ext2 and fat filesystems.

I also tried it with 2.2.18 there it works but it seems to be utterly
slow. I'm using kernel 2.4.2(XFS version to be precise).

Any solution to this problem?

Greetings,

Jurgen

Re: 2048 byte/sector problems with kernel 2.4

[Alan Cox]

> MO disks which have normal 512 bytes/sector it all works flawlessly but
> as soon
> as a put in a 1.3GB disk which uses the 2048 bytes/sector format it all
> goes
> wrong. As soon as I write something to the disk by issuing a cp command

It will. Linux 2.4.x still hasn't had the scsi disk block size bugs fixed.
Stick to 2.2.19.

> I also tried it with 2.2.18 there it works but it seems to be utterly
> slow. I'm using kernel 2.4.2(XFS version to be precise).

M/O disks are slow. At a minimum make sure you are using a physical block size
of 2048 bytes when using 2048 byte media and plenty of memory to cache stuff
when reading. Seek times on M/O media are pretty poor

Re: 2048 byte/sector problems with kernel 2.4

[Harvey Fishman]

On Tue, 3 Apr 2001, Alan Cox wrote:

> > I also tried it with 2.2.18 there it works but it seems to be utterly
> > slow. I'm using kernel 2.4.2(XFS version to be precise).
> 
> M/O disks are slow. At a minimum make sure you are using a physical block size
> of 2048 bytes when using 2048 byte media and plenty of memory to cache stuff
> when reading. Seek times on M/O media are pretty poor

Another thing making for the snailicity of MO drives is that writing is a
two pass operation.  It is very like core memory; first you write the spot
to a known state, and then you write the data.  So you have an average 
latency of 25 mS. for write operations and 8.33 mS. for read operations.
There WERE direct overwrite media for a while that would, in theory, be
able to write the data directly, but a combination of high cost, limited
sources, and strong questions about the permanence of the recorded data
severely limited the demand for these and I think that they have been
withdrawn.

Harvey

----------------------------------------------------------------------------
 Harvey Fishman   |
fishman@panix.com |           A little heresy is good for the soul.
  718-258-7276    |

RE: 2048 byte/sector problems with kernel 2.4

[Giuliano Pochini]

> I recently acquired a 1.3GB MO drive. When I use small (230MB and 540MB)
>
> MO disks which have normal 512 bytes/sector it all works flawlessly but
> as soon
> as a put in a 1.3GB disk which uses the 2048 bytes/sector format it all
> goes
> wrong. As soon as I write something to the disk by issuing a cp command
> the command
> just eats 99% CPU time and does not write a single byte to disk (it
> seems).

Hmm, I have no problems with 640MB disks with 2KB/sector (bot normal and
"overwrite" media). This  night I'll try with a 1.2GB disk. I'll let
you know.

> Is this a known problem ?

Only with FAT fs AFAIK. ext2 should work fine (or at least it works
fine for me since 2.1.153).

> I also tried it with 2.2.18 there it works but it seems to be utterly
> slow.

Yes, it's a request merging problem, fixed in 2.4.


Bye.
    Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-

Re: 2048 byte/sector problems with kernel 2.4

[John William]

On Tue, 3 Apr 2001, Harvey Fishman wrote:
>On Tue, 3 Apr 2001, Alan Cox wrote:
>
>> > I also tried it with 2.2.18 there it works but it seems to be >utterly 
>> > slow. I'm using kernel 2.4.2(XFS version to be precise).
>>
>>M/O disks are slow. At a minimum make sure you are using a physical >block 
>>size of 2048 bytes when using 2048 byte media and plenty of memory to 
>> >cache stuff when reading. Seek times on M/O media are pretty poor
>
>Another thing making for the snailicity of MO drives is that writing is >a 
>two pass operation. It is very like core memory; first you write the >spot 
>to a known state, and then you write the data. So you have an average 
>latency of 25 mS. for write operations and 8.33 mS. for read >operations. 
>There WERE direct overwrite media for a while that would, in theory, be 
>able to write the data directly, but a combination of high cost, >limited 
>sources, and strong questions about the permanence of the recorded data 
>severely limited the demand for these and I think that they have been 
>withdrawn.
>
>Harvey

No, direct overwrite disks are expensive, but they are still available. I do 
not know of any, and have not heard of any problems related to direct 
overwrite technology. For some reason M/O never really caught on in the US, 
and the high price of direct overwrite disks is what seems to be killing 
them off. I have a bunch I use for backup and have never had any problems.

Slow is a relative term. Compared to a Seagate X15? Yes, a M/O drive is 
probably slower. Compared to an 8X CD burner? No, my 640MB and 1.3GB M/O 
drives are quite a bit faster, particularly for random writes. For most 
applications, M/O is designed to compete with the latter, rather than the 
former.

People need to remember that M/O drives are meant to compete with CD-R or 
CD-RW as a moderate capacity, highly robust storage medium for archiving and 
backup. But it is somewhat annoying that 2.4.x doesn't (yet) support their 
2K sector sizes correctly.

- John

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: 2048 byte/sector problems with kernel 2.4

[Giuliano Pochini]

> >There WERE direct overwrite media for a while that would, in theory, be
> >able to write the data directly, but a combination of high cost, >limited
> >sources, and strong questions about the permanence of the recorded data
> >severely limited the demand for these and I think that they have been
> >withdrawn.

I have 2 OW disks and they work just fine. According to specs their
reliability is the same as nornal MO disks.

> No, direct overwrite disks are expensive, but they are still available. I do
> not know of any, and have not heard of any problems related to direct
> overwrite technology. For some reason M/O never really caught on in the US,
> and the high price of direct overwrite disks is what seems to be killing
> them off. I have a bunch I use for backup and have never had any problems.

RW CDs killed almost all removables.

And about 2KB sectors related problems, I confirm what I wrote in my previous
message: I have no problems. 640MB and 1.3GB both work fine here.

(kernel 2.4.3, old aic7xxx driver, adaptec 2930CU, Fujitsu GigaMO, PowerPC
750)

Bye.