Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx> writes:
> Hi,
>
>> But unless your drive firmware is broken the drive with only ever give
>> the correct data or an error. Smart has a counter for blocks that have
>> gone bad and will be fixed pending a write to them:
>> Current_Pending_Sector.
>>
>> The only way the drive should be able to give you bad data is if
>> multiple bits toggle in such a way that the ECC still fits.
>
> Not really, I've disks which are *perfect* in smart sense
> and nevertheless I had mistmatch count.
> This was a SW problem, I think now fixed, in RAID-10 code.
But that wasn't the drive giving you bad data. That was you writing
bad data in the first place. :)
> This means that, yes, there could be mismatches, without
> any warning, from other sources than disks.
> And these could be anywhere in the system.
> I already mentioned, time ago, a cabling problem which was
> leading to a similar result: wrong data on different disks,
> without any warning or error from the HW layer.
>
> That is why it is important to know *where* the mismatch
> occurs and, if possible, in which device component.
> If it is an empty part of the FS, no problem, if it
> belongs to a specific file, then it would be possible
> to restore/recreate it.
FULL ACK.
> Of course, a tool will be needed telling which file is
> using a certain block of the device.
>
> bye,
Filesystems usualy have such a tool. Worstcase write a little C
program that checks the FIBMAP of each file.
MfG
Goswin
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
