partitions and erase regions

partitions and erase regions

[Kári Davíðsson]

Hi,

I am implementing a "virtual" erase regions for partitions.
It looks to me that should be enough to create them in
add_mtd_partition().

This would make it easyer to manage partitions that cross erase region
boundaries.

Are there any reasons that this should not be done?

K.D.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: partitions and erase regions

[Kári Davíðsson]

Since there was no protest I just went ahead and commited the "virtual"
erase region
patch to mtdpart.

K.D.

> -----Original Message-----
> From: Kári Davíðsson 
> Sent: 29. mars 2001 17:04
> To: mtd@infradead.org
> Subject: partitions and erase regions
> 
> 
> Hi,
> 
> I am implementing a "virtual" erase regions for partitions.
> It looks to me that should be enough to create them in
> add_mtd_partition().
> 
> This would make it easyer to manage partitions that cross erase region
> boundaries.
> 
> Are there any reasons that this should not be done?
> 
> K.D.
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> 


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: partitions and erase regions

[Nicolas Pitre]

On Fri, 30 Mar 2001, Kári Davíðsson wrote:

> Since there was no protest I just went ahead and commited the "virtual"
> erase region
> patch to mtdpart.

Sorry, I apparently missed your original post.

> > Hi,
> >
> > I am implementing a "virtual" erase regions for partitions.
> > It looks to me that should be enough to create them in
> > add_mtd_partition().
> >
> > This would make it easyer to manage partitions that cross erase region
> > boundaries.

Why do you want to have partitions that cross erase region in the first
place?

The primary goal of partitions is to easily _preserve_ some parts of the
flash while allowing free access to others.  If a writable, ence eraseable,
partition can start/end up in the middle of an erase region, you will
potentially trash part of a contigous partition that was ment to be
read-only.  Even if you preserve the erased content of the contigous
partition to write it back afterwards, you still have the risk of a power
failure at the right time that would rander your read-only partition
corrupted.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: partitions and erase regions

[Kári Davíðsson]

> -----Original Message-----
> From: Florian Schirmer / TayTron [mailto:schirmer@taytron.net]
> Sent: 30. mars 2001 18:00
> To: Kári Davíðsson; mtd@infradead.org
> Subject: AW: partitions and erase regions
> 
> 
> Hi!
> 
> >Since there was no protest I just went ahead and commited 
> the "virtual"
> >erase region
> >patch to mtdpart.
> 
> Just a short question :-)
> 
> Situation:
> 
> 2 partitions not aligned to erase sectors. The first jffs and 
> the second
> cramfs. What happens if jffs writes to the last sector (the 
> shared one) and
> just in the second the block was erased the power fails. Data 
> loss on the
> second partition?

Well partition boundaries have to be on mtd.erasesize boundaries so that
can not happen.

> 
> If so please make virtual support a selectable option in 
> kernel config. (If
> not already)

Will do.

> 
> Thanks
>   Florian Schirmer

K.D.

> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> 


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: partitions and erase regions

[Kári Davíðsson]

> -----Original Message-----
> From: Nicolas Pitre [mailto:nico@cam.org]
> Sent: 30. mars 2001 17:53
> To: Kári Davíðsson
> Cc: mtd@infradead.org
> Subject: RE: partitions and erase regions
> 
> 
> 
> 
> On Fri, 30 Mar 2001, Kári Davíðsson wrote:
> 
> > Since there was no protest I just went ahead and commited 
> the "virtual"
> > erase region
> > patch to mtdpart.
> 
> Sorry, I apparently missed your original post.
> 
> > > Hi,
> > >
> > > I am implementing a "virtual" erase regions for partitions.
> > > It looks to me that should be enough to create them in
> > > add_mtd_partition().
> > >
> > > This would make it easyer to manage partitions that cross 
> erase region
> > > boundaries.

For my chip I have to fit bootrom in the first 0x20000 kb.
The first 0x10000 are 8 0x2000 sized sectors while the next 0x10000 
is one sector of size 0x10000. Because of the "stupid" way of reporting
the chip with only one sectorsize (mtd.erasesize) I am  unable to erase
and otherwaise manage this part of the chip.
The natural solution to me is to make the first part of the chip a
partition
with two erase regions, i.e. the first with erase size 0x2000 and 8
sectors
and the next with erase size 0x10000 and 1 sector.

> 
> Why do you want to have partitions that cross erase region in 
> the first
> place?

Well for the reason above. I do not have much chance.

> 
> The primary goal of partitions is to easily _preserve_ some 
> parts of the
> flash while allowing free access to others.  If a writable, 
> ence eraseable,

I am not giving that up.

> partition can start/end up in the middle of an erase region, you will
> potentially trash part of a contigous partition that was ment to be
> read-only.  Even if you preserve the erased content of the contigous
> partition to write it back afterwards, you still have the 
> risk of a power
> failure at the right time that would rander your read-only partition
> corrupted.
> 
> 
> Nicolas

What I think people are misundrestanding something here.

I am not making up erase regions of arbitrary size, but rather make 
the slave->mtd (in mtdpart.c) reflect what sectors and sizes are part
of the partition through erase regions. These "virtual" regions will
always have the same boundaries as the physical sectors and same 
erase size as the physical erase regions but the number of sectors in
each erase region is different from the physical number.

Regards,

K.D.

> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> 


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: partitions and erase regions

[David Woodhouse]

kd@flaga.is said:
>  For my chip I have to fit bootrom in the first 0x20000 kb. The first
> 0x10000 are 8 0x2000 sized sectors while the next 0x10000  is one
> sector of size 0x10000. Because of the "stupid" way of reporting the
> chip with only one sectorsize (mtd.erasesize) I am  unable to erase
> and otherwaise manage this part of the chip. The natural solution to
> me is to make the first part of the chip a partition with two erase
> regions, i.e. the first with erase size 0x2000 and 8 sectors and the
> next with erase size 0x10000 and 1 sector. 

(delayed reaction)

How about the following rules/behaviour for MTD partitions:

 1. For a partition to be writable, there must be a number usable as 'major'
	erasesize (mtd->erasesize), such that a naïve user of MTD can get 
	erases at offsets such that offset % erasesize == 0 to work.
 2. If a partition covers regions of the master which have differing 
	erasesizes, the information about the exact erase regions should
	be made available in the slave.

So... given a master device with 'major' erasesize 64K, which is actually 
8*8K, 15*64K, this would be the result of some example partitions...

 Partition range   Erase size(s)      Writable?

 000000 - 020000  64K (8*8K, 1*16K)	Yes
 020000 - 100000  64K			Yes

 000000 - 008000  8K			Yes
 008000 - 100000  -			No (no usable 'major' erasesize) 

 000000 - 010000  8K			Yes
 010000 - 100000  64K			Yes

 008000 - 010000  8K			Yes

Kári, if this is acceptable for your purposes (and I think it is), then we 
should just implement this behaviour and not have any conditional code at 
all.

/me wanders off to kick some sense into the new Red Hat 7.1 installation, 
which has taken it upon itself to randomly start correcting my spelling to 
some foreign language, and no longer approves of the word 'behaviour'.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: partitions and erase regions

[Kári Davíðsson]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: 23. apríl 2001 14:11
> To: Kári Davíðsson
> Cc: mtd@infradead.org; nico@cam.org
> Subject: Re: partitions and erase regions 
> 
> How about the following rules/behaviour for MTD partitions:
> 
>  1. For a partition to be writable, there must be a number 
> usable as 'major'
> 	erasesize (mtd->erasesize), such that a naïve user of 
> MTD can get 
> 	erases at offsets such that offset % erasesize == 0 to work.
>  2. If a partition covers regions of the master which have differing 
> 	erasesizes, the information about the exact erase regions should
> 	be made available in the slave.

It sounds reasonable to me. Although I have a problem with the "major"
erazesize in
general. The erase regions are in the flash for a reason, i.e. the chip
is not
of one "major" erase size but of many erase sizes, although most of it
(untill now, who knows what AMD, Intel and others might do in the future
8-))
is of one erase size. I think it should be a long term goal to remove
the
member "mtd->erasize". It might be irresponsible of me to say that since
it seems
that a lot of the code using mtd structure depend heavily on that
member.
It might also complicate the code a lot to always go through the erase
region
structures for every erase/[un]lock and slow down e.g. filesystems that
live on
the device. Modulo division is simple and fast no one can deny that 8-)
But on the other hand it also complicates the code to have two ways of
getting to a 
sector, i.e. mtd->erasesize and erase regions.....

> 
> So... given a master device with 'major' erasesize 64K, which 
> is actually 
> 8*8K, 15*64K, this would be the result of some example partitions...
> 
>  Partition range   Erase size(s)      Writable?
> 
>  000000 - 020000  64K (8*8K, 1*16K)	Yes
>  020000 - 100000  64K			Yes
> 
>  000000 - 008000  8K			Yes
>  008000 - 100000  -			No (no usable 'major' 
> erasesize) 
> 
>  000000 - 010000  8K			Yes
>  010000 - 100000  64K			Yes
> 
>  008000 - 010000  8K			Yes
> 
> Kári, if this is acceptable for your purposes (and I think it 
> is), then we 
> should just implement this behaviour and not have any 
> conditional code at 
> all.

Yes, I will try to get to it this week.


K.D.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: partitions and erase regions

[David Woodhouse]

kd@flaga.is said:
> It sounds reasonable to me. Although I have a problem with the "major"
> erazesize in general. The erase regions are in the flash for a reason,
> i.e. the chip is not of one "major" erase size but of many erase
> sizes, although most of it (untill now, who knows what AMD, Intel and
> others might do in the future 8-)) is of one erase size.

I have a strong suspicion that we'll never see chips without a 'major' 
erasesize. Making all clients (such as JFFS2) deal with variable erase 
sizes is possible, but IMHO suboptimal. If we can avoid that complexity, it 
would be nice. 

Perhaps, however, we should provide a way for clients which _do_ know about 
variable erase regions to write to partitions which don't have a 'major' 
erasesize.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: partitions and erase regions

[Kári Davíðsson]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: 24. apríl 2001 17:41
> To: Kári Davíðsson
> Cc: mtd@infradead.org; nico@cam.org
> Subject: Re: partitions and erase regions 
> 
> 
> 
> kd@flaga.is said:
> > It sounds reasonable to me. Although I have a problem with 
> the "major"
> > erazesize in general. The erase regions are in the flash 
> for a reason,
> > i.e. the chip is not of one "major" erase size but of many erase
> > sizes, although most of it (untill now, who knows what AMD, 
> Intel and
> > others might do in the future 8-)) is of one erase size.
> 
> I have a strong suspicion that we'll never see chips without 
> a 'major' 

Yes you are probably right.

> erasesize. Making all clients (such as JFFS2) deal with 
> variable erase 
> sizes is possible, but IMHO suboptimal. If we can avoid that 
> complexity, it 
> would be nice.

Of course, but I was kind of arguing that maybe it might even be
simpler (code wise) to have one access mechanism to the sector
boundaries
rather than two. And we can not get away with the simple offset %
mtd->erasesize 
because of the 'minor' erase sizes.

I have not checked the client codes or where the mtd->erasesize is used,
but I
have an image in my head that is something like,

erase_regions * er;

//Used instead of offset % mtd->erasesize == 0
//returns 0 if on sector boundary
//nonzero otherwise
int mtd_er_isonboundary(er, offset);

//returns the size from offset to next sector boundary
int mtd_er_sizeleft(er, offfset);

There might be couple of other methods necessary, depeneding on how the
mtd->erasesize member is used.

How does JFFS[2] deal with the whole flash chip today?
If it just deals with 'major' erase size then it shurely must
simply ingore the first/last part (with 'minor' erase sizes) of the
chip.

> 
> Perhaps, however, we should provide a way for clients which 
> _do_ know about 
> variable erase regions to write to partitions which don't 
> have a 'major' 
> erasesize.

Yes, that was my thinking of the "virtual erase region" code.

> 
> --
> dwmw2

K.D.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: partitions and erase regions

[David Woodhouse]

kd@flaga.is said:
>  How does JFFS[2] deal with the whole flash chip today? If it just
> deals with 'major' erase size then it shurely must simply ingore the
> first/last part (with 'minor' erase sizes) of the chip. 

It just ignores the fact that it has minor erase sizes. If you have 8*8K + 
15*64K, then JFFS2 will just treat all the 8 minor blocks as a single 
normal-sized block, and will only ever ask the flash driver to erase them 
all together.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: partitions and erase regions

[David Woodhouse]

kd@flaga.is said:
> If you call erase at offset 0x0 for 8*8K + 15*64K only the first
> sector i.e. first 8K is erased not all 8 sectors.

Erase requests have a length in them.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org