[PATCH] Adding eraseblock header support(revised version)

[zhao forrest]

>
>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.
>
1 According to the later disscusion in "1:1 mapping" thread, we should
reject mounting when detect cross-boundary. In another word, we should
not reject mounting if we don't detect cross-boundary. Right? This is
just what my patch implemented :)

2 The reason why we introduce JFFS2_NODETYPE_INODE_EBH has nothing to
do with "when an old JFFS2 image is mounted by new JFFS2 code". It's
related with "when an new JFFS2 image is mounted by old JFFS2 code".
Your original design mail for eraseblock header has a clear description
of it.
So the problem is still open:
Whether should we set the compat flag of eraseblock_header to
RWCOMPAT_DELETE or INCOMPAT???

Thanks,
Forrest