[PATCH] [JFFS2] check xattr data integrity during the scan.

Artem Bityutskiy dedekind1 at gmail.com
Sun Apr 22 09:04:32 EDT 2012


On Wed, 2012-04-11 at 22:23 +0200, Jean-Christophe DUBOIS wrote:
> If the system was powered off while JFFS2 was creating or moving
> (GC) an extended attribute node, it might happen at next reboot
> that the node CRC is OK but the data (name and value) might be
> incomplete and therefore corrupted.
> 
> During the mount scan we need to check the xattr data integrity to
> weed out bad ones and keep good ones (whith an earlier version).
> 
> Whitout this check the xattr data integrity problem was detected
> a lot later and was not cured automatically (-EIO was returned).
> 
> Signed-off-by: Jean-Christophe DUBOIS <jcd at tribudubois.net>
> ---

AFAIR, the whole idea of having 2 CRC checksums in JFFS2 nodes is to
speed up scanning. E.g., if we hit an inode node, we check only
"node_crc" to validate the "metadata", insert the inode to the in-memory
data structures, and read the next node. We do not check the data CRC
(data_crc), otherwise scanning would be much slower. If the data are
corrupted, we notice this later, wen reading it.

The same is done for xattrs - during scanning we do not check the data
payload.

I do not say this is ideal design, but it is how it is. So I do not
think your patch should be merged.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120422/851487a3/attachment.sig>


More information about the linux-mtd mailing list