Re: Corrupt empty space

[Artem Bityutskiy <dedekind1@gmail.com>]

On Fri, 2014-03-21 at 08:43 +0100, Ricard Wanderlof wrote:
> On Fri, 21 Mar 2014, Artem Bityutskiy wrote:
> 
> > On Fri, 2014-03-21 at 07:18 +0000, Gupta, Pekon wrote:
> >> It's still getting discussed in [a] and [b]. But there are multiple issues to it.
> >>
> >>  (1) Many hardware controllers cannot parse ECC errors in blank-pages.
> >>    So, checking number of 0-bits in a page is done in software by comparing
> >>    each byte with 0xff.
> >
> > OK.
> >
> >> (2) Counting number of 0-bits in a page in software, brings down your read-performance.
> >
> > UBIFS _only_ needs this when doing recovery, which is _only_ done after
> > unclean reboots, and this kind of reads would be done _only_ for a
> > couple of max I/O units and _only_ if there is a corrupted node in the
> > journal.
> >
> > IOW, this would be done rarely, and for just few pages on mount.
> 
> What about when attaching a UBI volume to a completely a erased partition? 
> I would assume that with the EC and VID headers thus missing, that UBI 
> would erase each block prior to writing the headers, and then knowing that 
> they were erased not need to check for 0xff in the blocks?

Hmm, yeah, I missed this case, thanks.

> Admittedly this would only happen once in a products lifetime so even if 
> UBI did need to scan each block, it won't have much of an impact on 
> performance, except possibly that the additional time would be spent in 
> production where time is a premium.

Yeah, I guess you are right.

-- 
Best Regards,
Artem Bityutskiy