reach of jffs2 within image vs. partition

reach of jffs2 within image vs. partition

[John Burch]

Will JFFS2 ever read/write an area of flash memory that is within the
same mtd partition but outside of the jffs2 image (as defined -p switch
of mkfs.jffs2)?  In other words, if the jffs2 image spans 0x0 - 0x120000
and it lies within an mtd partition that spans 0x0 - 0x140000, will the
last 128k, spanning from 0x120000 - 0x140000, ever be accessed in any
way by jffs2?  Would that 128k area be as safe/non-volatile there as in
a separate partition?
 
Thanks,
John
 

Re: reach of jffs2 within image vs. partition

[David Woodhouse]

On Wed, 2003-04-02 at 14:06, John Burch wrote:
> Will JFFS2 ever read/write an area of flash memory that is within the
> same mtd partition but outside of the jffs2 image (as defined -p switch
> of mkfs.jffs2)?  In other words, if the jffs2 image spans 0x0 - 0x120000
> and it lies within an mtd partition that spans 0x0 - 0x140000, will the
> last 128k, spanning from 0x120000 - 0x140000, ever be accessed in any
> way by jffs2?  Would that 128k area be as safe/non-volatile there as in
> a separate partition?

No. JFFS2 will use the entire partition regardless of the amount of
space taken by the original image.

-- 
dwmw2

RE: reach of jffs2 within image vs. partition

[John Burch]

> -----Original Message-----
> From: linux-mtd-bounces@lists.infradead.org 
> [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of 
> David Woodhouse
> Sent: Wednesday, April 02, 2003 8:11 AM
> To: John Burch
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: reach of jffs2 within image vs. partition
> 
> 
> On Wed, 2003-04-02 at 14:06, John Burch wrote:
> > Will JFFS2 ever read/write an area of flash memory that is 
> within the 
> > same mtd partition but outside of the jffs2 image (as defined -p 
> > switch of mkfs.jffs2)?  In other words, if the jffs2 image 
> spans 0x0 - 
> > 0x120000 and it lies within an mtd partition that spans 0x0 - 
> > 0x140000, will the last 128k, spanning from 0x120000 - 
> 0x140000, ever 
> > be accessed in any way by jffs2?  Would that 128k area be as 
> > safe/non-volatile there as in a separate partition?
> 
> No. JFFS2 will use the entire partition regardless of the 
> amount of space taken by the original image.

Thanks.
  
Is there any advantage or disadvantage to creating the jffs2 image file
with the exact same size (via padding) as the partition, as opposed to
creating the jffs2 image with some size that's less than the partition
size?

> 
> -- 
> dwmw2
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list 
> http://lists.infradead.org/mailman/listinfo/li> nux-mtd/
> 

RE: reach of jffs2 within image vs. partition

[David Woodhouse]

On Wed, 2003-04-02 at 14:41, John Burch wrote:
> Is there any advantage or disadvantage to creating the jffs2 image file
> with the exact same size (via padding) as the partition, as opposed to
> creating the jffs2 image with some size that's less than the partition
> size?

Not generally, no.

If you use the 'cleanmarker' option then it'll prevent the kernel from
erasing the remaining blocks on the first mount, and with some
bootloaders you can't define a partition while installing an image which
is smaller than the total intended size of that partition -- so you had
to pad with 0xFF to avoid writing crap to the end of it.

-- 
dwmw2

Re: reach of jffs2 within image vs. partition

[Jörn Engel]

On Wed, 2 April 2003 14:44:56 +0100, David Woodhouse wrote:
> On Wed, 2003-04-02 at 14:41, John Burch wrote:
> > Is there any advantage or disadvantage to creating the jffs2 image file
> > with the exact same size (via padding) as the partition, as opposed to
> > creating the jffs2 image with some size that's less than the partition
> > size?
> 
> Not generally, no.
> 
> If you use the 'cleanmarker' option then it'll prevent the kernel from
> erasing the remaining blocks on the first mount, and with some
> bootloaders you can't define a partition while installing an image which
> is smaller than the total intended size of that partition -- so you had
> to pad with 0xFF to avoid writing crap to the end of it.

In my experience, better always use images of the same size as the
partition.

You don't *have* to, but then some will figure out how to not erase
the partition, write the image to it, remount the partition and find
some old data in the filesystem that was supposed to be erased.

Give people the option to shoot themselves in the foot and eventually
someone will do it - and blame you. ;)

Jörn

-- 
When you close your hand, you own nothing. When you open it up, you
own the whole world.
-- Li Mu Bai in Tiger & Dragon

Re: reach of jffs2 within image vs. partition

[David Woodhouse]

On Wed, 2003-04-02 at 15:03, Jörn Engel wrote:
> In my experience, better always use images of the same size as the
> partition.
> 
> You don't *have* to, but then some will figure out how to not erase
> the partition, write the image to it, remount the partition and find
> some old data in the filesystem that was supposed to be erased.
> 
> Give people the option to shoot themselves in the foot and eventually
> someone will do it - and blame you. ;)

Oh yeah, that too -- good point :)

-- 
dwmw2

Re: reach of jffs2 within image vs. partition

[Thomas Gleixner]

On Wednesday 02 April 2003 15:06, John Burch wrote:
> Will JFFS2 ever read/write an area of flash memory that is within the
> same mtd partition but outside of the jffs2 image (as defined -p switch
> of mkfs.jffs2)?  In other words, if the jffs2 image spans 0x0 - 0x120000
> and it lies within an mtd partition that spans 0x0 - 0x140000, will the
> last 128k, spanning from 0x120000 - 0x140000, ever be accessed in any
> way by jffs2?  Would that 128k area be as safe/non-volatile there as in
> a separate partition?
JFSS2 is mounted on a partition and accesses the hole partition. 
If you want to reserve an aera in your flash chip for other purposes, put this 
area in a seperate partition.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de