[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