Re: [PATCH] tango_nand.c: fix ecc.stats_corrected in empty flash case

From: Pavel Machek <pavel@ucw.cz>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>,
	Thibaud Cornic <thibaud_cornic@sigmadesigns.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Mason <slash.tmp@free.fr>
Subject: Re: [PATCH] tango_nand.c: fix ecc.stats_corrected in empty flash case
Date: Wed, 17 May 2017 14:04:30 +0200	[thread overview]
Message-ID: <20170517120430.GB32246@amd> (raw)
In-Reply-To: <20170504104216.0969423f@bbrezillon>

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

Hi!

> > > Hello Pavel,
> > > 
> > > You may have noticed that ecc_stats.corrected is not updated in
> > > decode_error_report() which is the main code path, i.e. the path
> > > that will succeed 99.99% of the time (HW read).
> > > 
> > > It turns out that the HW does not report the number of errors
> > > corrected in a page... Instead it reports two values:
> > > 1) U = number of errors corrected in the first packet/step
> > > 2) V = max number of errors corrected in other packets/steps
> > > 
> > > Thus, it is not possible to determine the actual number of errors
> > > corrected in a page (unless V is 0). Otherwise, we just have an
> > > interval; let n be the number of packets/steps:
> > > 
> > > U + V <= corrected errors count <= U + (n-1)*V
> > > 
> > > In my opinion, it is better to provide no information than to
> > > provide incorrect information. Therefore, I did not update
> > > ecc_stats.corrected in decode_error_report().  
> > 
> > Well... Having corrected ECC errors is pretty rare, right?
> 
> Depends on the NAND chip. On modern SLC NAND chips requiring
> ECC of 8bits/512bytes are likely to have frequent bitflips.
> 
> > So one
> > solution would be to re-compute ECCs in software if we see U or V >
> > 0...
> 
> Hm, not sure it's worth the trouble for statistics that are anyway
> rarely used, and when they are, are only used has a metric to determine
> how worn the NAND is.

Well, knowing "how worn the NAND is" and "when to refresh the
data". Both seem to be quite important for storage system that works.

> I'd prefer to see a better user-space interface returning the
> max_bitflips information when someone reads from an MTD device (see [1])
> rather than trying to fix drivers to return the exact number of
> corrected bitflips (which might be impossible for some of them anyway).
> 
> > [1]http://lists.infradead.org/pipermail/linux-mtd/2016-April/067187.html

Yes, current interface leaves something to be desired...

Best regards,
										Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]