Re: [RFC PATCH] UBIFS: remove check for all(0xff) for empty pages

[Matthieu CASTET <matthieu.castet@parrot.com>]

Le Tue, 11 Mar 2014 09:42:46 +0200,
Artem Bityutskiy <dedekind1@gmail.com> a écrit :

> On Tue, 2014-03-11 at 11:53 +0530, Pekon Gupta wrote:
> 
> However, there is one type of corruptions we _did_ want to gracefully
> handle - corruptions caused by power cuts.
> 
> So in the kernel space we tried to be very very careful in
> distinguishing between power cut corruptions and random corruptions.
> 
> Now, power cut corruptions have the following properties:
> 
> 1. Can only happen in journal LEBs.
> 2. Happen only in one single write unit (max_write_size), because UBIFS
> always writes one write unit (or less) at a time.
> 3. The next write unit (the one coming after the corrupted write unit)
> should be empty, never written to. Just because we write unit after unit
> sequentially.
> 
I think this is not true with MLC flash that Pekon want to handle.

There is the paired page problem [1] and the power cut corruption can
happen in more than one page.



[1]
[NEED WORK] There is another aspect of MLC flashes which may need closer attention: the "paired pages" problem (e.g., see this Power Point presentation). Namely, MLC NAND pages are coupled in a sense that if you cut power while writing to a page, you corrupt not only this page, but also one of the previous pages which is paired with the current one. For example, pages 0 and 3, 1 and 4, 2 and 5, 3 and 6 in and so on (in the same eraseblock) may be paired (page distance is 4, but there may be other distances). So if you write data to, say, page 3 and cut the power, you may end up with corrupted data in page 0. UBIFS is not ready to handle this problem at the moment and this needs some work.

UBIFS can handle this problem by avoiding using the rest of free space in LEBs after a sync or commit operation. E.g., if start writing to a new journal LEB, and then have a sync or commit, we should "waste" some amount of free space in this LEB to make sure that the previous paired page does not contain synced data. This way we guarantee that a power cut will not corrupt the synced or committed data. And the "wasted" free space can be re-used after that LEB has been garbage-collected. Similar to all the other LEBs we write to (LPT, log, orphan, etc). This would require some work and would make UBIFS slower, so this should probably be optional. The way to attack this issue is to improve UBIFS power cut emulation and implement "paired-pages" emulation, then use the integck test for testing. After all the issues are fixed, real power-cut tests could be carried out.