From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [195.209.228.254] (helo=shelob.oktetlabs.ru)
	by canuck.infradead.org with esmtps (Exim 4.52 #1 (Red Hat Linux))
	id 1E4eBn-0001hB-Fz
	for linux-mtd@lists.infradead.org; Mon, 15 Aug 2005 08:35:44 -0400
Message-ID: <43008BFB.502@yandex.ru>
Date: Mon, 15 Aug 2005 16:35:07 +0400
From: "Artem B. Bityuckiy" <dedekind@yandex.ru>
MIME-Version: 1.0
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
References: <42E5ECE5.4010901@inf.u-szeged.hu>	<20050726093215.GD15903@wohnheim.fh-wedel.de>	<20050726100330.GF15903@wohnheim.fh-wedel.de>	<42EDF04C.1010108@inf.u-szeged.hu>	<20050801095645.GA32464@wohnheim.fh-wedel.de>	<42EDF470.4060208@inf.u-szeged.hu>	<20050801104343.GB32464@wohnheim.fh-wedel.de>	<42EE2B78.70500@inf.u-szeged.hu>	<20050801141841.GD32464@wohnheim.fh-wedel.de>	<42FB68AE.6070805@inf.u-szeged.hu>	<20050815094816.GA27229@wohnheim.fh-wedel.de>	<43007773.2070602@yandex.ru>
	<43008129.2060303@inf.u-szeged.hu>
In-Reply-To: <43008129.2060303@inf.u-szeged.hu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH]fs/jffs2/wbuf.c: add compatibility support for OOB data
 block
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
	<mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

Ferenc Havasi wrote:
> No. The task of this condition is to make sure that the summary was 
> generated correctly. If the summary is generated by the filesystem, it 
> will be always good, but you are also able to generate summary with the 
> userspace tool 'sumtool'. If we do not recognise this mistake that can 
> cause big problems and make the user confused.
> 
Err, do you mean that sumtool may generate summary with wrong erase_size?

Well, but my assumption is also valid. Glance at fs.c:466

c->sector_size = c->mtd->erasesize;
blocks = c->flash_size / c->sector_size;
if (!(c->mtd->flags & MTD_NO_VIRTBLOCKS)) {
     while ((blocks * sizeof (struct jffs2_eraseblock)) > (128 * 1024)) {
         blocks >>= 1;
         c->sector_size <<= 1;
     }
}

Here the size of eraseblock depends on sizeof(struct jffs2_eraseblock). 
You increase the size of 'struct jffs2_eraseblock'. So, you may have a 
situation when one mounts an *old* image with *new* JFFS2 with *summary 
enabled*, and JFFS2 uses *larger* virtual eraseblock size, because

blocks * sizeof (struct jffs2_eraseblock)) > (128 * 1024)

condition is changed.

How is this situation handled?

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