diff options
| author | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2010-10-29 01:34:50 -0400 |
|---|---|---|
| committer | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2011-02-06 12:19:41 -0500 |
| commit | fef2deb31f6523203a3fa1af485a5f1fef19cf6b (patch) | |
| tree | d29f44eeb247b72329e0e16e19399dd4b83e5e26 /drivers/mtd | |
| parent | 6c1e875ca6f3a47b40dce715bd07fdfdb8388d55 (diff) | |
UBI: cleanup comments about corrupted PEBs
Just make them a bit more readable and explanatory.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'drivers/mtd')
| -rw-r--r-- | drivers/mtd/ubi/scan.c | 54 |
1 files changed, 34 insertions, 20 deletions
diff --git a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c index 0028bf283930..b65cc088fde5 100644 --- a/drivers/mtd/ubi/scan.c +++ b/drivers/mtd/ubi/scan.c | |||
| @@ -39,32 +39,46 @@ | |||
| 39 | * eraseblocks are put to the @free list and the physical eraseblock to be | 39 | * eraseblocks are put to the @free list and the physical eraseblock to be |
| 40 | * erased are put to the @erase list. | 40 | * erased are put to the @erase list. |
| 41 | * | 41 | * |
| 42 | * About corruptions | ||
| 43 | * ~~~~~~~~~~~~~~~~~ | ||
| 44 | * | ||
| 45 | * UBI protects EC and VID headers with CRC-32 checksums, so it can detect | ||
| 46 | * whether the headers are corrupted or not. Sometimes UBI also protects the | ||
| 47 | * data with CRC-32, e.g., when it executes the atomic LEB change operation, or | ||
| 48 | * when it moves the contents of a PEB for wear-leveling purposes. | ||
| 49 | * | ||
| 42 | * UBI tries to distinguish between 2 types of corruptions. | 50 | * UBI tries to distinguish between 2 types of corruptions. |
| 43 | * 1. Corruptions caused by power cuts. These are harmless and expected | 51 | * |
| 44 | * corruptions and UBI tries to handle them gracefully, without printing too | 52 | * 1. Corruptions caused by power cuts. These are expected corruptions and UBI |
| 45 | * many warnings and error messages. The idea is that we do not lose | 53 | * tries to handle them gracefully, without printing too many warnings and |
| 46 | * important data in these case - we may lose only the data which was being | 54 | * error messages. The idea is that we do not lose important data in these case |
| 47 | * written to the media just before the power cut happened, and the upper | 55 | * - we may lose only the data which was being written to the media just before |
| 48 | * layers (e.g., UBIFS) are supposed to handle these situations. UBI puts | 56 | * the power cut happened, and the upper layers (e.g., UBIFS) are supposed to |
| 49 | * these PEBs to the head of the @erase list and they are scheduled for | 57 | * handle such data losses (e.g., by using the FS journal). |
| 50 | * erasure. | 58 | * |
| 59 | * When UBI detects a corruption (CRC-32 mismatch) in a PEB, and it looks like | ||
| 60 | * the reason is a power cut, UBI puts this PEB to the @erase list, and all | ||
| 61 | * PEBs in the @erase list are scheduled for erasure later. | ||
| 51 | * | 62 | * |
| 52 | * 2. Unexpected corruptions which are not caused by power cuts. During | 63 | * 2. Unexpected corruptions which are not caused by power cuts. During |
| 53 | * scanning, such PEBs are put to the @corr list and UBI preserves them. | 64 | * scanning, such PEBs are put to the @corr list and UBI preserves them. |
| 54 | * Obviously, this lessens the amount of available PEBs, and if at some | 65 | * Obviously, this lessens the amount of available PEBs, and if at some point |
| 55 | * point UBI runs out of free PEBs, it switches to R/O mode. UBI also loudly | 66 | * UBI runs out of free PEBs, it switches to R/O mode. UBI also loudly informs |
| 56 | * informs about such PEBs every time the MTD device is attached. | 67 | * about such PEBs every time the MTD device is attached. |
| 57 | * | 68 | * |
| 58 | * However, it is difficult to reliably distinguish between these types of | 69 | * However, it is difficult to reliably distinguish between these types of |
| 59 | * corruptions and UBI's strategy is as follows. UBI assumes (2.) if the VID | 70 | * corruptions and UBI's strategy is as follows. UBI assumes corruption type 2 |
| 60 | * header is corrupted and the data area does not contain all 0xFFs, and there | 71 | * if the VID header is corrupted and the data area does not contain all 0xFFs, |
| 61 | * were not bit-flips or integrity errors while reading the data area. Otherwise | 72 | * and there were no bit-flips or integrity errors while reading the data area. |
| 62 | * UBI assumes (1.). The assumptions are: | 73 | * Otherwise UBI assumes corruption type 1. So the decision criteria are as |
| 63 | * o if the data area contains only 0xFFs, there is no data, and it is safe | 74 | * follows. |
| 64 | * to just erase this PEB. | 75 | * o If the data area contains only 0xFFs, there is no data, and it is safe |
| 65 | * o if the data area has bit-flips and data integrity errors (ECC errors on | 76 | * to just erase this PEB - this is corruption type 1. |
| 77 | * o If the data area has bit-flips or data integrity errors (ECC errors on | ||
| 66 | * NAND), it is probably a PEB which was being erased when power cut | 78 | * NAND), it is probably a PEB which was being erased when power cut |
| 67 | * happened. | 79 | * happened, so this is corruption type 1. However, this is just a guess, |
| 80 | * which might be wrong. | ||
| 81 | * o Otherwise this it corruption type 2. | ||
| 68 | */ | 82 | */ |
| 69 | 83 | ||
| 70 | #include <linux/err.h> | 84 | #include <linux/err.h> |