[Oberon] Reason for 'read pio error' ?

Andreas Dörr andreas.doerr at workingobjects.de
Sun Sep 1 23:34:44 CEST 2002


>A disk block is 512 bytes.  So lba 12991229 translates to about
>6.2GB (6.5GB metric).  You didn't say what the disk size is, but I
>assume it is larger than this.

Yes. It is a 18GB disk.

>Looking at AosATADisks.ReadPIO, it seems error 2820 is generated when
>the ERR bit is set after a command.
>
>At what stage does this error occur?  I assume during Partitions.Format?

Exactly.

>I'm not sure why the driver sees this ERR bit, and as you say, modern
>disks should remap bad sectors automatically.  I'm not sure if they
>can do this without OS support.  Perhaps the OS is required to retry
>a failed transfer?  But then a second Partitions.Format should work...

I have tried to format the partition several times. The error remains constant.

Concerning the automatic remapping of bad sectors. My current theory is, 
that the controller is only able to do this after a low level format marks 
the bad sectors. Maybe someone could provide more definite information ...

>Unfortunately this is currently the only workaround, since the AosFS
>file system does not handle bad blocks.  What needs to be done is:
>
>1. detect bad blocks in Partitions.Format
>2. create a file that contains all these bad blocks

Well I guess, almost all file systems suppose to operate on a perfect 
media. I would not expect bad block handling from AosFS.

Creating a file that contains all these bad blocks is the most 
straightforward solution to the problem. From my point of view it has the 
following drawback: Save access to a partition containing a bad sector file 
is only possible on file level. Any tool accessing the partition on disk 
block level will fail.

For this solution a new common "BadBlock" error code needs to be introduced 
to interface module "AosDisks". Otherwise a high level module like 
"Partitions" would be bound to an error code coming from an implementation 
of the interface module "AosDisks" (in this case "AosATADisk").

Another solution would be to implement bad sector forwarding on the disk 
driver level. This solution is transparent to all higher levels. It is even 
possible to access the partition on block level. In BSD based Unix system 
the command "bad144" does this.

Essentially at the end of each partition some space is reserved for bad 
sector information and a list of replacement sectors. Whenever the disk 
device driver receives a read or write error it will use a replacement 
sector instead of the bad sector.

I'm not sure which solution is more appropriate. The bad block file 
solution is easier to implement. So, maybe we should start with this one ...

>If someone wants to attempt this, I suggest taking the relevant
>Format code from Partitions.Mod and rewriting it in a new module.

Since I own the "offending" disk, I will try to do this. As a first step I 
will implement a command which creates a file containing a given list of 
bad blocks. If this is done, I will adapt the formatting code in 
Partitions.Mod. At first I will directly check for AosATADisk.Mod pio read 
and pio write error codes. However, in the long run AosATADisk.Mod should 
convert these error codes to a common error code defined in AosDisks.Mod. 
Any idea, how the original error code could be preserved? 
Controller.Transfer() only returns one result code.

Do you have any suggestion for the name the bad block file should have?

Since I still have to learn a lot about Bluebottle, I will definitely need 
your assistance ...

--Andreas





More information about the Oberon mailing list