diff options
author | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2010-09-03 20:08:15 (GMT) |
---|---|---|
committer | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2010-10-19 14:19:57 (GMT) |
commit | 5fc01ab6934c43b42c41bc753fe1123c16d7f38f (patch) | |
tree | 174a1e1a0d283ec8ca4c756d7f354a475ac46a36 /drivers/mtd/ubi/scan.h | |
parent | feeba4b872e5166ca64c44fbb5bbec234dfce199 (diff) | |
download | linux-fsl-qoriq-5fc01ab6934c43b42c41bc753fe1123c16d7f38f.tar.xz |
UBI: preserve corrupted PEBs
Currently UBI erases all corrupted eraseblocks, irrespectively of the nature
of corruption: corruption due to power cuts and non-power cut corruption.
The former case is OK, but the latter is not, because UBI may destroy
potentially important data.
With this patch, during scanning, when UBI hits a PEB with corrupted VID
header, it checks whether this PEB contains only 0xFF data. If yes, it is
safe to erase this PEB and it is put to the 'erase' list. If not, this may
be important data and it is better to avoid erasing this PEB. Instead,
UBI puts it to the corr list and moves out of the pool of available PEB.
IOW, UBI preserves this PEB.
Such corrupted PEB lessen the amount of available PEBs. So the more of them
we accumulate, the less PEBs are available. The maximum amount of non-power
cut corrupted PEBs is 8.
This patch is a response to UBIFS problem where reporter
(Matthew L. Creech <mlcreech@gmail.com>) observes that UBIFS index points
to an unmapped LEB. The theory is that corresponding PEB somehow got
corrupted and UBI wiped it. This patch (actually a series of patches)
tries to make sure such PEBs are preserved - this would make it is easier
to analyze the corruption.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'drivers/mtd/ubi/scan.h')
0 files changed, 0 insertions, 0 deletions