2048 byte/sector problems with kernel 2.4
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
Quoted 5 lines
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.
Quoted 2 lines
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
Quoted 6 lines · Alan Cox
Quoted 2 lines
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 | [email protected] | A little heresy is good for the soul. 718-258-7276 |
Quoted 11 lines
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.
Quoted 1 line
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).
Quoted 2 lines
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} ->)|(<-