1:1 mapping

[Jörn Engel]

On Fri, 23 September 2005 10:10:15 +0200, Ferenc Havasi wrote:
> zhao forrest wrote:
> 
> > Your patch may have problem.
> > In fact this "reject to mount when cross-boundary" has been in my
> > patch, it's quite simple. This code segment is extracted from my patch:
> >
> > @@ -570,10 +584,8 @@ scan_more:
> >              /* Eep. Node goes over the end of the erase block. */
> >         printk(KERN_WARNING "Node at 0x%08x with length 0x%08x would
> > run over the end of the erase block\n",
> >                               ofs, je32_to_cpu(node->totlen));
> > -        printk(KERN_WARNING "Perhaps the file system was created
> >           with the wrong erase size?\n");
> > -                       DIRTY_SPACE(4);
> > -                       ofs += 4;
> > -                       continue;
> > +                       printk(KERN_NOTICE "Perhaps the file system
> >       was created with the wrong erase size? Reject to mount.\n");
> > +                       return -EINVAL;
> >                }
> 
> My patch has one more part: detecting that case, if the node header is
> also cross-boundary. But that case we cannot say: it is absolutely sure
> that it is a cross-boundary node, just can say: it is likely.
> 
> Forutnatelly the node header is small enough to say that if someone uses
> bad (larger) erase block size, there will be a cross-boundary node which
> have a correct node header at the end of the erase block, and only the
> body is cross-boundary.
> 
> So If everyone agrees we can commit this small part of Zhao's patch.

Actually, I preferred your patch:
o -EIO makes slightly more sense than -EINVAL.
o Detecting nodes with headers crossing the boundary also makes sense.

The shorter string constant of Zhao's patch, on the other hand,
reduces binary size and should be enough.  People will report problem
to the mailing list and get pointed in the right direction.

I'll try to have a better look over the weekend.

Jörn

-- 
It's just what we asked for, but not what we want!
-- anonymous