Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: dedekind1@gmail.com
Cc: MTD Maling List <linux-mtd@lists.infradead.org>
Subject: Re: Grow UBI device?
Date: Tue, 15 Oct 2013 19:40:31 +0200	[thread overview]
Message-ID: <20131015174031.E52CF380420@gemini.denx.de> (raw)
In-Reply-To: <1381393038.7875.83.camel@sauron.fi.intel.com>

Dear Artem,

In message <1381393038.7875.83.camel@sauron.fi.intel.com> you wrote:
> Wolfgang, people already answered you, and frankly I did not read all
> the answers :-) But here is my brief version.

Thanks.

> On Tue, 2013-10-08 at 21:28 +0200, Wolfgang Denk wrote:
> > I'm looking for a clever way to migrate devices (in the field) from
> > JFFS2 to UBI/UBIFS.  In the end result, I want to have single UBI
> > device (which covers the whole NAND chip) with several volumes used
> > with UBIFS.  Unfortunately I must keep some of the existing data.
> 
> And I guess there is no temporary storage where you could copy JFFS2
> files, re-format the flash, and copy the files back.

Correct.

> > It would be nice if I could start with a UBI device that is smaller
> > than the NAND, so I can keep an existing MTD partition with a JFFS2
> > file system.
> 
> You mean that on the existing systems, you already have an extra MTD
> partition, or you somehow can create one.
> 
> Then you want to UBI/UBIFS-format the extra partition. Then copy
> required JFFS2 files there. And then kill JFFS2 partitions and "merge"
> them with the extra partition, and end up with UBI/UBIFS covering all
> the space.

Correct.

> > Is there a way to "grow" the existing UBI device so that it now also
> > covers the rest of the NAND chip?  Or is my only option to create a
> > second UBI device?
> 
> I think so, unless you use the fastmap feature. Suppose you don't.

We don't.  We may want to do this later, but certainly not during this
migration steps.

> 1. Format mtd2 with UBI. Just erasing should be OK, or you can use
> ubiformat: http://www.linux-mtd.infradead.org/faq/ubi.html#L_ubierase
> 
> Then you attach mtd2 (ubiattach) and you get an UBI device (/dev/ubiX).
> 
> 2. Create a volume on /dev/ubiX which spans entire UBI device
> (ubimkvol -t AFAIR). You end up with UBI volume /dev/ubiX_0.
> 
> 3. And here is important part - you format /dev/ubiX_0 with JFFS2 but
> correctly.

With JFFS2?  I would expect to see "UBIFS" here?

> UBIFS has this "automatic expand" feature. Which means that if the UBI
> volume underneath it becomes larger, UBIFS will expand automatically and
> take the entire (larger) UBI volume.
> 
> However, there is a _limit_ to how much UBIFS can expand from the
> original size. And you want to watch this limit and make it big enough.
> 
> The limit is connected with the "-c" option of mkfs.ubifs. Please, check
> the docs - they explain what exactly -c controls and how it is related
> to the maximum UBIFS file-system size:
> 
> http://www.linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt
> 
> So, select proper -c.

Thanks for the poointer.  I would have missed this.

> If you do not use mkfs.ubifs, but just attach /dev/ubiX_0, the UBIFS
> kernel driver will format the volume automatically. It will select the
> -c value itself. Since this value is power of 2, it will just take the
> smallest power-of-2 value. It may be OK for your purposes, may be not.
> It is safer to use mkfs.ubifs with explicit -c.

Agreed.  It would have worked in our case, as mtd1 is 32 MB and mtd2
is 96 MB on a 128 MB NAND device, but it's much better to have full
control.

> 4. Copy important files from JFFS2-mtd1 to UBIFS-UBI-mtd2.
> 
> 5. Erase mtd1 (or you can do this later too)
> 
> 6. I do not know how you do this, but kill mtd1, and resize mtd2.
> Probably mtd2 will then be named mtd1 after reboot. If you always refer
> your MTD partitions and UBI volumes by name, you should not suffer to
> much from mtd2 becoming mtd1.

The plan is to just have another mtd3 which covers the whole device.
So I would detach UBI from mtd2 and re-attach to mtd3.

> Lets suppose there is no rename, for simplicity.
> 
> 7. Make sure former JFFS2-mtd1 eraseblocks are erased (unless you did
> this at step 5).
> 
> 8. Attach mtd2 to UBI. UBI will automatically "take" the new
> eraseblocks, erase them and write UBI headers there, and make available.
> 
> 9. Volume size will still be the same, and you need to re-size it using
> ubiresize.
> 
> 10. Mount the resized volume. UBI will enlarge itself.

That's just amazing :-)

> Problem solved.
> 
> Surely you do not want power cuts during this operations. If you need to
> survive power cuts, I guess it is possible, but more complex.

Thanks a lot for all the help, it's highly appreciated!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"At least they're __________EXPERIENCED incompetents"

  parent reply	other threads:[~2013-10-15 17:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08 19:28 Grow UBI device? Wolfgang Denk
2013-10-09  7:28 ` Matthieu CASTET
2013-10-09  8:46 ` Ricard Wanderlof
2013-10-09 11:28   ` Gupta, Pekon
2013-10-09 15:05     ` Wolfgang Denk
2013-10-09 15:45       ` Ricard Wanderlof
2013-10-09 18:47         ` Richard Weinberger
2013-10-09 20:01         ` Wolfgang Denk
2013-10-10  7:42     ` Artem Bityutskiy
2013-10-09 14:33   ` Wolfgang Denk
2013-10-10  8:17 ` Artem Bityutskiy
2013-10-10  8:34   ` Richard Weinberger
2013-10-15 17:40   ` Wolfgang Denk [this message]
2013-10-15 18:38     ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131015174031.E52CF380420@gemini.denx.de \
    --to=wd@denx.de \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox