Re: [PATCH 0/3] MTD: Change meaning of -EUCLEAN return code on reads

Artem Bityutskiy
2012-03-16T12:46:59Z

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

> Consider the following situation:
> - a NAND device with 2kB pages and 4 ecc steps per page (4 x 512 bytes)
> - the driver has chip->ecc.strength = 4, and therefore mtd->ecc_strength = 16

I would expect in this case we should have mtd->ecc_strength = 4 anyway.

> So my point is that the cleaning decision happens at the ecc step level,
> not at the page reading level.

I agree, good point.

> I think this could be fixed by dropping 'ecc_strength' and changing the semantics
> of 'bitflip_threshold' in the following way (rephrasing your explanation):
>
> (3) The drivers' read methods, absent an error, return a non-negative integer
> indicating the maximum number of bit errors that were corrected in any one
> ecc step. MTD returns -EUCLEAN if this is >= bitflip_threshold, 0
> otherwise.
>
> So basically, the meaning of -EUCLEAN is changed from "one or more bit errors
> were corrected", to "a dangerously high number of bit errors were corrected on
> one or more ecc step block". By default, "dangerously high" is interpreted
> as chip->ecc.strength. Drivers can specify a different value, and the user can
> override it if more or less caution regarding data integrity is desired.
>
> But still, there is a problem: how do we implement (3), i.e. how do we know
> "the maximum number of bit errors that were corrected in any one ecc step" ?
>
> Just looking at ecc_stats.corrected is not enough, as it accumulates over each
> ecc step result, and does not allow us to distinguish cases 1 and 2 (from my
> previous example). Maybe we could have per-step ecc stats ? or have the driver
> return directly the information ?

Yeah, sounds like we should have per-step stats.

--
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]