[TUHS] Disk data layout (was: /dev/drum)

[bakul@bitblocks.com (Bakul Shah)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

@Fortune Systems we kept a forwarding map of bad blocks. This was
stored in a file at inode#1 IIRC. To read/write block n you check if n was in
the list. If not, you read/write disk block n. Else you use the mapped block.
The last N blocks were reserved for this. Actually we had to keep some
state. A block that gave an error on read was marked bad so that further
reads errored out. But a write to such a block would allocate a new block and
add an entry in the bad block forwarding map. Further read/writes would then
Go to this block. I also kept soft (correctable) error stats. These blocks were
more likely to go bad so periodically a background task would preemptively
forward these blocks. To test this logic I used to build the v7 kernel on a very unreliable disk! But this slowed things down a lot - having to seek to the end
zone and then back for the next block. I think in later disk drives an extra block
per track was reserved for this and the drive took care of this.

It would’ve made more sense to avoid this forwarding by exposing bad blocks
to the file system layer so that it can avoid allocating them but this would’ve
complicated the interface.

> On Apr 25, 2018, at 2:17 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> How does/did Unix handle bad block replacement?