Re: [PATCH] Adding eraseblock header support(revised version)

["Artem B. Bityutskiy" <dedekind@yandex.ru>]

zhao forrest wrote:
> According to the comments from mailing list, one problem is
> still open:
> Whether should we set the compat flag of eraseblock_header to
> RWCOMPAT_DELETE or INCOMPAT? Now in my patch I still set the compat flag 
> of eraseblock_header
> to INCOMPAT. After the final decision is made, I can modify
> the patch accordingly.
> 
Well, this was discussed... But I still don't see any conclusion. My
opinion is below.

Terms:
1. New JFFS2 - recent JFFS2 where 1:1 was added.
2. Old JFFS2 - older JFFS2, before 1:1 was added.
3. New JFFS2 image - an image made for new JFFS2.
4. Old JFFS2 image - an image made for old JFFS2.

Q: are there any issues when an old JFFS2 image is mounted by new JFFS2
code?
A: yes, there are. Old JFFS2 did eraseblock concatenations and worked
with virtual eraseblocks. So, there are nodes which cross the eraseblock
boundary.

Q: why is this a problem?
A: because with 1:1 mapping we will have nodes which cross the
eraseblock boundary. JFFS2 will suffer hard.

Q: what to do?
A: either handle this or reject mounting old images in New JFFS2.

Thus, my answer is - yes, you must reject mounting old images.

But this has no relation to your parch. Could you implement that by a
distinct patch please? Or Ferenc, who actually committed the 1:1 patch
may do this :-) (please).

You may implement it like this. If you have met any clean marker during
scan - reject mounting JFFS2. No need to introduce messy
JFFS2_NODETYPE_INODE_EBH and the like.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.