[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