06.08.2013 Views

pSOSystem System Calls - Read

pSOSystem System Calls - Read

pSOSystem System Calls - Read

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

pHILE+ <strong>System</strong> <strong>Calls</strong> verify_vol<br />

TABLE 2-3 Extent Map Faults<br />

VF_EXTIN An indirect block contains an extent containing an illegal<br />

block.<br />

VF_INIX An index block contains an illegal indirect block number.<br />

VF_LLBIX Within an index block, the LLB associated with an indirect<br />

block is incorrect.<br />

VF_DBDA A directory block resides in the data area of the volume.<br />

VF_INDA An indirect block resides in the data area of the volume.<br />

VF_IXDA An index block resides in the data area of the volume.<br />

Bad Blocks<br />

A bad block is a block that cannot be read and/or written and therefore cannot be<br />

used by pHILE+ file system manager. There are a number of possible strategies for<br />

handling bad blocks. One strategy is to mask or redirect them at the driver level so<br />

that pHILE+ file system manager never sees them. Another method, which is<br />

described here in detail, involves “mapping out” those blocks in the volume’s<br />

bitmap, so that they are never allocated by pHILE+ file system manager.<br />

verify_vol() facilitates such modifications to the bitmap.<br />

Recall that each volume contains a bitmap describing which blocks on the volume<br />

are in use, and which are free. If the corresponding bit in the map is set to 1, the<br />

block is considered to be in use; otherwise, it is considered to be available for<br />

allocation by the pHILE+ file system manager when needed. If the bit corresponding<br />

to a bad block can be set to 1 before the block is allocated, then the pHILE+ file<br />

system manager will never allocate the block, and hence will never read or write it.<br />

To facilitate bad block handling, verify_vol() accepts as an input parameter a<br />

list of bad blocks. When examining the volume’s bitmap, verify_vol() expects<br />

bits corresponding to these bad blocks to be set to 1, while at the same time<br />

expecting the block to be unused. If a bad block is in use, or its corresponding bit is<br />

not set, a fault is generated.<br />

The remainder of this section gives a brief outline of a recommended method for<br />

handling bad blocks.<br />

There are two types of bad blocks:<br />

Dead Blocks — These blocks are known to be bad prior to volume initialization. They<br />

are normally the result of manufacturing defects. Typically, the device<br />

<strong>pSO<strong>System</strong></strong> <strong>System</strong> <strong>Calls</strong> 2-139<br />

2

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!