On 2010-02-23 at 17:43 -0500, Benjamin Scott wrote:
> On Tue, Feb 23, 2010 at 2:01 PM, Michael Bilow
> wrote:
>> During the md check operation, the array is "clean" (not degraded)
>> and you can see that explicitly with the "[UU]" status report ...
>
> Of course, mdstat still calls the array "clean" even after
> mismatches are detected, which isn't what I'd usually call "clean"...
> :-)
Ther term "clean" in this context just means that all of the RAID
components (physical drives) are still present.
>> It is not a "scrub" because it does not attempt to repair anything.
>
> Comments in previously mentioned config file don't make it sound
> like that. "A check operation will scan the drives looking for bad
> sectors and automatically repairing only bad sectors." It doesn't
> explain how it would repair bad sectors. Perhaps it means the bad
> sectors will be "repaired" by failing the entire member and having the
> sysadmin insert a new disk. Perhaps the comments are just wrong.
>
> Not arguing with you, just reporting what the file told me. Would
> the file lie? ;-)
That's sort of true and sort of not true, but generally outdated. It
is important to appreciate that the "md" device operates at a level
of abstraction above block devices that isolates it from low-level
details that are handled by whatever driver manages the block
devices. For something like a parallel IDE drive -- or, heaven
forbid, an ST-506 drive -- there is not a lot of intelligence on
board the drive that will mask error conditions: a read error is a
read error.
When SCSI (meaning SCSI-2) was developed, it provided for a ton of
settable parameters, some vendor-independent and some proprietary.
Among these were mode page bits that controlled what the device
would do by default on encountering errors during read or write,
notably the "ARRE" (automatic read reallocation) and "AWRE"
(automatic write reallocation) bits. Exactly what a device does when
these bits are asserted is not too well specified, especially
considering that a disk and a tape may have radically different
ranges of options but use the same basic SCSI command set. In
practice, I can't think of any reasonable way to implement ARRE:
it's almost always worse to return bad data from a read operation
with a success code than to just have the read operation report a
failure code outright.
(ATA is essentially a protocol for wrapping SCSI commands and
responses into packets for non-SCSI devices, so the logic applies.)
>> Detecting and reporting "soft failure" incidents
>> such as reallocations of spare sectors ...
>
> The relocation algorithm in modern disks generally works like this
> (or so I'm told):
>
> R1. OS requests read logical block from HDD. HDD tries to read from
> block on disk, and can't, even with retries and ECC. HDD returns
> failure to the OS, and marks that physical block as "bad" and as a
> candidate for relocation.
At this point, an unreadable block encountered on a block device is
handled at a very high level, usually the file system, well above
where things like AWRE on the hardware can occur. This is where the
"md" driver will intervene, attempting to reconstruct the unreadable
block from its reservoir of redundancy (the other copy if RAID-1,
the other stripes if RAID-5). If the "md" driver can reconstruct the
unreadable data, it will attempt to write the correct data back to
the block device: at this point, the hardware may reallocate a spare
sector for the new data. Unless a write occurs somehow, though, even
with AWRE enabled the hardware should not reallocate a sector.
When a write succeeds and forces an AWRE event, the hardware
test-reads the newly written data and returns an error if the data
could not be verified. By this stage, the "md" device may have had
cause to mark the whole block device as bad and degrade the array.
> R2. Repeated attempts by OS to read from the same block cause the HDD
> to retry. It won't throw away your data on its own.
Correct, in all practical cases the hardware will never reallocate a
bad block on read operations. The SCSI protocol provides for ARRE,
but as I noted this is never really implemented.
> R3. OS requests write to same logical block. HDD relocate to
> different physical block, and throws away the bad block. It can do
> that now, since you've told it you don't want the data that was there,
> by writing new data over it.
Again, exactly what happens is going to vary a lot with the
particular hardware. Older drives, even parallel ATA drives,
generally cannot reallocate a spare sector on the fly during normal
operation, but can only do it during a low-level format operation of
the whole drive. This is because the reserve of spare sectors on
such drives is associated with physical zones, so that reallocation
can only occur during a track-granular write operation.
In my experience, nearly all SCSI drives have AWRE disabled from the
factory, and it is up
