From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
Cc: zhao forrest <zhao_fusheng@hotmail.com>, linux-mtd@lists.infradead.org
Subject: Re: 1:1 mapping
Date: Fri, 23 Sep 2005 11:02:48 +0200 [thread overview]
Message-ID: <20050923090248.GC7522@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <4333B867.4050801@inf.u-szeged.hu>
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
next prev parent reply other threads:[~2005-09-23 9:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-22 12:20 1:1 mapping Jörn Engel
2005-09-22 13:05 ` Josh Boyer
2005-09-22 13:21 ` Jörn Engel
2005-09-22 13:41 ` Artem B. Bityutskiy
2005-09-22 13:48 ` Jörn Engel
2005-09-22 13:54 ` Artem B. Bityutskiy
2005-09-22 14:02 ` Jörn Engel
2005-09-22 23:48 ` Ferenc Havasi
2005-09-23 2:33 ` zhao forrest
2005-09-23 8:10 ` Ferenc Havasi
2005-09-23 9:02 ` Jörn Engel [this message]
2005-09-23 2:56 ` zhao forrest
2005-09-23 9:08 ` Jörn Engel
2005-09-23 3:03 ` zhao forrest
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050923090248.GC7522@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=havasi@inf.u-szeged.hu \
--cc=linux-mtd@lists.infradead.org \
--cc=zhao_fusheng@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox