Re: [PATCH 4.4 15/47] ubi: fastmap: Correctly handle interrupted erasures in EBA

[Ben Hutchings <ben.hutchings@codethink.co.uk>]

On Thu, 2018-07-26 at 08:25 +0200, Richard Weinberger wrote:
> Ben,
> 
> Am Donnerstag, 26. Juli 2018, 04:12:54 CEST schrieb Ben Hutchings:
> > On Tue, 2018-07-10 at 20:24 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Richard Weinberger <richard@nod.at>
> > > 
> > > commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
> > > 
> > > Fastmap cannot track the LEB unmap operation, therefore it can
> > > happen that after an interrupted erasure the mapping still looks
> > > good from Fastmap's point of view, while reading from the PEB will
> > > cause an ECC error and confuses the upper layer.
> > > 
> > > Instead of teaching users of UBI how to deal with that, we read back
> > > the VID header and check for errors. If the PEB is empty or shows ECC
> > > errors we fixup the mapping and schedule the PEB for erasure.
> > 
> > [...]
> > 
> > Isn't there a risk here, that a read error leads to erasing data that
> > might be recoverable if the read is retried?
> 
> Well, read error means that already something went very wrong. At other places
> in UBI wo also don't retry reading headers and consider it as fatal when we 
> are unable to read it.
> We could also read the EC header, but what do we gain from that?
> If the VID header is not readable we cannot check fastmap either.
> 
> What case exactly do you have in mind?

I suppose I'm thinking about data recovery from a flash device that has
become unreliable.  I'm not familiar with ubi; is there a read-only
mode where the erase wouldn't actually be performed?

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom