All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH mtd-www] UBI FAQ: suggest omission of vol_size option
@ 2012-04-04 21:27 Daniel Drake
  2012-04-13 17:17 ` Artem Bityutskiy
  0 siblings, 1 reply; 2+ messages in thread
From: Daniel Drake @ 2012-04-04 21:27 UTC (permalink / raw)
  To: linux-mtd

OLPC set vol_size based on the size of the target NAND and found out
that it resulted in some systems being unbootable, where such systems
had a lot of bad blocks on their flash.

For distributors such as OLPC wishing to maximize robustness in the
face of varying bad block counts, it makes a lot of sense to avoid
the vol_size option and let it be calculated automatically.
Document this.

Signed-off-by: Daniel Drake <dsd@laptop.org>
---
 faq/ubi.xml |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/faq/ubi.xml b/faq/ubi.xml
index 7133867..c9f1c57 100644
--- a/faq/ubi.xml
+++ b/faq/ubi.xml
@@ -299,6 +299,20 @@ actually has to be at least 225MiB in size. Of course it may be larger,
 in which case the "rootfs" volume will be re-sized and take the rest of the
 flash space (because of the auto-resize flag).</p>
 
+<p>
+The implications of the above paragraph are important. The
+<code>vol_size</code> option effectively represents the minimum size of the
+flash where the volume will be installed. If you are working with multiple
+devices (i.e. you are producing an image to be flashed on various devices,
+even when 'identical'), the amount of usable flash <em>will</em> vary because
+some devices have more bad blocks than others. Excluding the
+<code>vol_size</code> option will cause vol_size to be automatically
+calculated based on the size of the input image, and this will produce
+maximum robustness in the face of varying numbers of bad blocks on target
+devices. You can combine this with the autoresize functionality so that the
+maximum amount of free space is made available upon first mount.
+</p>
+
 <p>Also, the <code>config_data.img</code> and <code>rootfs.img</code> input
 files do not have to be 512KiB and 220MiB respectively, but may be smaller if
 they contain less data. In this case the resulting <code>ubi.img</code> file
-- 
1.7.7.6

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

* Re: [PATCH mtd-www] UBI FAQ: suggest omission of vol_size option
  2012-04-04 21:27 [PATCH mtd-www] UBI FAQ: suggest omission of vol_size option Daniel Drake
@ 2012-04-13 17:17 ` Artem Bityutskiy
  0 siblings, 0 replies; 2+ messages in thread
From: Artem Bityutskiy @ 2012-04-13 17:17 UTC (permalink / raw)
  To: Daniel Drake; +Cc: linux-mtd

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Wed, 2012-04-04 at 22:27 +0100, Daniel Drake wrote:
> OLPC set vol_size based on the size of the target NAND and found out
> that it resulted in some systems being unbootable, where such systems
> had a lot of bad blocks on their flash.
> 
> For distributors such as OLPC wishing to maximize robustness in the
> face of varying bad block counts, it makes a lot of sense to avoid
> the vol_size option and let it be calculated automatically.
> Document this.
> 
> Signed-off-by: Daniel Drake <dsd@laptop.org>

Pushed both to mtd-www, thanks a lot!

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

end of thread, other threads:[~2012-04-13 17:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-04 21:27 [PATCH mtd-www] UBI FAQ: suggest omission of vol_size option Daniel Drake
2012-04-13 17:17 ` Artem Bityutskiy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.