Re: UBI/UBIFS: dealing with MLC's paired pages

[Stefan Roese <sr@denx.de>]

Hi,

On 24.09.2015 09:43, Boris Brezillon wrote:
>> 2. EC/VID header corruption
>> 	As Boris's excellent summary mentioned, "duplicate the EC header in the VID header", I also believe this is a good
>> 	solution to protect EC, and we are doing this and testing on MLC.
>> 	
>> 	For VID header, I think skip pages will waste too many capacity, and SLC mode conjugation with GC will make PE cycling higher.
>>
>> 	We are developing another solution to store VID info into other page's OOB area in its own block, because UBI does not
>> 	use OOB and ECC code always not use all OOB area.
>>
>
> Hm, using the OOB area to do that is not such a good idea IMO, and I see
> at least 2 reasons:
>
> 1/ You're supposing that you'll always have enough space to store the
> VID info (the header is currently taking 64 bytes, even if we could
> compress it by removing the padding), and this is not necessarily true
> (particularly with some NAND controllers which are allowing as much
> space as possible for ECC bytes).
>
> 2/ Most of the time ECC bytes are not protected (and even if some
> controllers are able to protect a few of them, we're not sure to have 64
> bytes of protected OOB bytes per page), which means you're writing
> something that can be corrupted by bitflips. I know that the header is
> protected by a CRC, but that won't help recovering the data, just let
> you know when the header is corruption.

And 3:
Only NAND provides an OOB area. Other flash devices like parallel
or SPI NOR don't. And we definitely want to continue supporting
platforms with such flash devices and UBI (and UBIFS).

Thanks,
Stefan