From what I have found so far on UBIFS' web page:
integrity - UBIFS (as well as UBI) checksums everything it writes to the flash media to guarantee data integrity, UBIFS does not leave data or meta-data corruptions unnoticed (JFFS2 is doing the same); By default, UBIFS checks only meta-data CRC when it reads from the media, but not the data CRC; however, you may force CRC checking for data using one of the UBIFS mount options - see here.
If you need to check filesystem for corruption
If your
UBIFS
filesystem is mounted with chk_data_crc
option, then simple cat $FILES > /dev/null
should be sufficient. If not, you can only detect and recover metadata corruption. The corruption of file body will pass unnoticed.
I used something like
find / -type f -print -exec cat {} + > /dev/null
If you need to recover broken files
Again from the overview section:
to make it more clear, imaging you have wiped out the FAT table on your FAT file system; for FAT FS this would be fatal; but if you similarly wipe out UBIFS index, you still may re-construct it, although a special user-space tool would be required to do this (this utility is not implemented at the moment, though)
While theoretically possible, you're on your own.
Back up the flash contents, arm yourself with UBIFS data structures (maybe sources) and a hex editor, and good luck.
edit: As I figured, Linux's MTD driver already applies ECC (error correction code) to MTD devices.
I believe, the criterion for a data loss if there are more than
/sys/class/mtd/mtd*/ecc_strength
errors per /sys/class/mtd/mtd*/ecc_step_size
flash block. mtd_read()
(it's a MTD API one level below UBIFS) will return EUCLEAN
in this case. Don't know if there exists a tool that uses it to check for errors.
The "bit flipped" warnings we get do not mean that there was a data loss yet. You can write to
/sys/class/mtd/mtd*/bitflip_threshold
to control the amount of warnings you get.
沒有留言:
張貼留言