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

[Artem Bityutskiy]

Hi Jean-Christophe,

On Sun, 2012-04-22 at 18:17 +0200, Jean-Christophe DUBOIS wrote:
> > The same is done for xattrs - during scanning we do not check the data
> > payload.
> In case of attributes, JFFS2 do detect that they are corrupted later but 
> it is too late. At that time we have lost reference to earlier 
> "versions" of the attribute and I think we would need to rescan the all 
> partition to find it back (assuming it has not been deleted in the mean 
> time as I am not sure how GC deals with earlier versions of the 
> attributes). So it seems better to do it in the first place.

Wait. Now I think I starting remembering a bit more. First of all, you
surely have many good arguments. But my counter-argument - the same
happens for data nodes. We do not check data CRC during scanning. Xattr
nodes should be treated the same way.

JFFS2 scans in 2 phases:
1. early scanning - it scans only the headers of the nodes, but not the
payloads. No I/O on the FS is possible.
2. late background scanning - the GC threads goes through every single
inode and reads it, so forces data CRC checking. JFFS2 is available for
reading, but write requests may block (if they require GC, AFAIR,
because we cannot do GC before we have checked everything, otherwise we
may lose a valuable older node version).

So I guess this is what you should do for xattrs as well - check payload
CRC at the second stage scanning, not the first one.

The idea on this split was to do minimum and make the FS available for
reading, and continue the rest in background. This background thing is
quite heavy BTW, and slows down the entire system boot.

> You also have to consider that attributes are generally "short" (unlike 
> the file content) and there is not much data associated to them. so the 
> overhead implied by the attribute data scanning is not very important 
> (considering the attribute data is already in memory). But it is true 
> that there is an overhead added by this patch.
> What happen for now is that if an attribute is corrupted, then we will 
> not be able to ever read it again (JFFS2 returns a negative/recoverable 
> error on corruption detection on any access and does not try to cure the 
> problem).

AFAIU, this should be dealt with during the second stage scanning.

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