Re: [RFC][PATCH 0/7] UBI checkpointing support

[Richard Weinberger]

Am 07.03.2012 17:33, schrieb Artem Bityutskiy:
> Just basic questions to make sure I understand things correctly.
>
> Do you have plans to also change the user-space tools?

Maybe ubiattach to make the attach method selectable.
Attaching by scanning or checkpointing...

> On Tue, 2012-02-14 at 21:06 +0100, Richard Weinberger wrote:
> > 1) A primary checkpoint block, which contains merily a pointer to the
> >     erase block(s) which hold the real checkpointing data.
> >
> >     This primary block is guaranteed to be held within the first N
> >     eraseblocks of a device. N is momentarily set to 16, but it might
> >     be necessary to make this configurable in some way.
>
> Does it mean that you reserve the first 16 PEBs for the primary block?

The current implementation selects out one of the first 64 blocks.
I know I wrote 16 in the initial RFC, but it's 64.
But it does not reserve them.

While writing a new checkpoint it tries to select an other early block.
If no new early block is available it reuses the old one.

> I guess we need to carefully look an this number and make the default to
> be good enough for the general case.

Yep. The current number was chosen randomly. :D

> > 2) The secondary checkpoint blocks, which contain the real
> >     checkpointing data (physical to logical eraseblock relations,
> >     erase counts, sequence numbers ...)
>
> >     Aside of that the checkpointing data contains a list of blocks
> >     which belong to the active working pool. The active working pool is
> >     a fixed number of blocks for shortterm, longterm and unknown
> >     storage time, which can be modified before the next checkpoint set
> >     is written to FLASH. These blocks need to be scanned in the
> >     conventional UBI scan mode.
>
> BTW, WRT short-term etc - how about just killing these concepts? I am
> really not sure they make much sense anyway and give any improvements.

Good idea!

> I guess this would simplify things for you as well. I'd vote for
> removing them.
>
> >     The reason for these pool blocks is to reduce the checkpoint
> >     updates to the necessary minimum to avoid accelerated device
> >     wearout in scenarios where data changes rapidly. The checkpoint
> >     data is updated whenever a working pool runs out of blocks.
> >
> >     The number of pool blocks can be defined with a config option at
> >     the moment, but this could also be done at runtime via sysfs. In
> >     case of a change the checkpointing data would be reconstructed.
>
> Id suggest to introduce as few configuration knob as possible. My
> experience show that they usually only hurt. I'd stick to this rule for
> most cases: no user, no knob.

Yeah.

> > So the checkpoint scan consists of the following steps:
> >
> >     1) Find the primary checkpoint block by scanning the start of the
> >        device.
> >
> >     2) Read the real checkpoint data and construct the UBI device info
> >        structures.
> >
> >     3) Scan the pool blocks.
> >
> > All these operations scan a limited number of erase blocks which makes
> > the UBI init O(1) and independent of the device size.
>
> Well, is it really true? The larger is the flash the more you read and
> process anyway, and it is still linear, but the multiplier becomes very
> small, so this is a huge improvement.

Yes. :)

Using checkpointing UBI only has to scan a fixed (independent of the 
flash size!) number of blocks.

> > The checkpoint functionality is fully compatible with existing UBI
> > deployments. If no checkpoint blocks can be found then the device is
> > scanned and the checkpoint blocks are created from the scanned
> > information.
> >
> > Aside of review and testing it needs to be decided, whether the number
> > of pool blocks should be deduced from the device size (number of
> > physical eraseblocks) or made configurable at compile or runtime.
>
> I would go for automatic decisions. Manual configuration can always be
> added later if needed.
>
> > Thanks to the folks at CELF who sponsored this work!
>
> Indeed thanks! And thank you Richard!

Thanks,
//richard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/