Corrupt empty space
Artem Bityutskiy
dedekind1 at gmail.com
Fri Mar 21 03:53:49 EDT 2014
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
More information about the linux-mtd
mailing list