linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [RFC v2] UBI: UBIVIS (aka checkpointing) support
@ 2012-05-09 17:38 Richard Weinberger
  2012-05-09 17:38 ` [PATCH 1/7] [RFC] UBI: Add checkpoint on-chip layout Richard Weinberger
                   ` (7 more replies)
  0 siblings, 8 replies; 19+ messages in thread
From: Richard Weinberger @ 2012-05-09 17:38 UTC (permalink / raw)
  To: linux-mtd; +Cc: Heinz.Egger, linux-kernel, tglx, tim.bird, dedekind1

The following patch set implements UBIVIS (checkpointing) support for
UBI.

Changes since v1:
        - renamed it to UBIVIS (at least in Kconfig)
        - UBIVIS parameters are now configurable via Kconfig
        - several bugs have been fixed (design and implementation bugs)
        - added lots of comments to make the review process easier
        - made checkpatch.pl happy

Currently I'm testing UBIVIS on different workloads to find bugs
and good configuration parameters (mostly for the pool size).
So, expect v3 soon! :-)

Description:

Checkpointing is an optional feature which stores the physical to
logical eraseblock relations in a checkpointing superblock to reduce
the initialization time of UBI. The current init time of UBI is
proportional to the number of physical erase blocks on the FLASH
device. With checkpointing enabled the scan time is limited to a fixed
number of blocks.

Checkpointing does not affect any of the existing UBI robustness
features and in fact the checkpointing code falls back into scanning
mode when the checkpoint superblock(s) are corrupted.

The checkpoints consist of two elements:

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 64, this value can
   be changed via Kconfig.

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.

   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.

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.

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.

Thanks to the folks at CELF who sponsored this work!

[PATCH 1/7] [RFC] UBI: Add checkpoint on-chip layout
[PATCH 2/7] [RFC] UBI: Add checkpoint struct to ubi_device
[PATCH 3/7] [RFC] UBI: Export next_sqnum()
[PATCH 4/7] [RFC] UBI: Export compare_lebs()
[PATCH 5/7] [RFC] UBI: Make wl subsystem checkpoint aware
[PATCH 6/7] [RFC] UBI: Implement checkpointing support
[PATCH 7/7] [RFC] UBI: wire up checkpointing

Thanks,
//richard

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2012-05-11 19:15 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-09 17:38 [RFC v2] UBI: UBIVIS (aka checkpointing) support Richard Weinberger
2012-05-09 17:38 ` [PATCH 1/7] [RFC] UBI: Add checkpoint on-chip layout Richard Weinberger
2012-05-11 11:17   ` Artem Bityutskiy
2012-05-11 12:02     ` Richard Weinberger
2012-05-11 12:21       ` Artem Bityutskiy
2012-05-11 17:15         ` Richard Weinberger
2012-05-11 18:56           ` Artem Bityutskiy
2012-05-11 19:15             ` Richard Weinberger
2012-05-09 17:38 ` [PATCH 2/7] [RFC] UBI: Add checkpoint struct to ubi_device Richard Weinberger
2012-05-09 17:38 ` [PATCH 3/7] [RFC] UBI: Export next_sqnum() Richard Weinberger
2012-05-09 17:38 ` [PATCH 4/7] [RFC] UBI: Export compare_lebs() Richard Weinberger
2012-05-09 17:38 ` [PATCH 5/7] [RFC] UBI: Make wl subsystem checkpoint aware Richard Weinberger
2012-05-09 17:38 ` [PATCH 6/7] [RFC] UBI: Implement checkpointing support Richard Weinberger
2012-05-09 17:38 ` [PATCH 7/7] [RFC] UBI: wire up checkpointing Richard Weinberger
2012-05-10  4:26 ` [RFC v2] UBI: UBIVIS (aka checkpointing) support Artem Bityutskiy
2012-05-10  8:33   ` Richard Weinberger
2012-05-11 10:46     ` Artem Bityutskiy
2012-05-11 10:49       ` Richard Weinberger
2012-05-11 11:26         ` Artem Bityutskiy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).