[PATCH v7 3/5]: mtdoops: Make page (record) size configurable

[Simon Kagstrom]

On Fri, 23 Oct 2009 07:13:49 +0300
Artem Bityutskiy <dedekind1 at gmail.com> wrote:

> On Thu, 2009-10-15 at 09:47 +0200, Simon Kagstrom wrote:
> > The main justification for this is to allow catching long messages
> > during a panic, where the top part might otherwise be lost since moving
> > to the next block can require a flash erase.
> > 
> > Signed-off-by: Simon Kagstrom <simon.kagstrom at netinsight.net>
> > Reviewed-by: Anders Grafstrom <anders.grafstrom at netinsight.net>
> 
> What will happen if I have a partition with 8192-bytes records, and then
> attach it to mtdoops with default 4096 ?

Assuming you have a crash stored, it will keep the first 4KB of it and
mark the second 4KB as unclean. This will then trigger an erase where
it will first move to the next erase block above and erase that (see
mtdoops_inc_counter and mtdoops_workfunc_erase).

So until you've wrapped around to the 8KB record again, it will be
kept. Userspace code to readout the mtdoops partition would have to be
prepared for different sized blocks in this case.


In practice, I think that it's best to erase the oops area if you
decide to change the size.

> >  	cxt->mtd = mtd;
> >  	if (mtd->size > INT_MAX)
> > -		cxt->oops_pages = INT_MAX / OOPS_PAGE_SIZE;
> > +		cxt->oops_pages = INT_MAX / record_size;
> >  	else
> > -		cxt->oops_pages = (int)mtd->size / OOPS_PAGE_SIZE;
> > +		cxt->oops_pages = (int)mtd->size / record_size;
> 
> BTW, this INT_MAX and the (int) cast also suggests we need to limit the
> maximum partition size and add a check for this.

OK, I'll make a patch to limit this.

// Simon