Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: MTD Maling List <linux-mtd@lists.infradead.org>,
	Ricard Wanderlof <ricard.wanderlof@axis.com>
Subject: Re: Grow UBI device?
Date: Wed, 09 Oct 2013 17:05:38 +0200	[thread overview]
Message-ID: <20131009150538.BAD57380432@gemini.denx.de> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA20350@DBDE04.ent.ti.com>

Dear "Gupta, Pekon",

In message <20980858CB6D3A4BAE95CA194937D5E73EA20350@DBDE04.ent.ti.com> you wrote:
>
> > > 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. After copying the data from JFFS2 to a UBIFS volume, I
> > > would like to free and reuse the space of this JFFS2 partition.
> > >
> That seems to be a nice move, but where would you copy the existing
> JFFS2 data ?

Well, I wrote: "copy[...] the data from JFFS2 to a UBIFS volume".

> (a) In memory, then there is threat of losing the data due to
>   power-failure, and you should have enough RAM.
> (b) copy to target UBIFS volume/partition. So assumption is that target
>   UBI volume has enough space and is writable.
> I'm assuming (b) is more workable .. 

...which is what I'm after.

> > Come to think of it, I'm not sure that would work anyway, as the
> > resulting, new, enlarged partition would partly contain UBI data and
> > partly old jffs2 data. I'm not sure what UBI does when it encounters
> > incorrect data, if it just erases the relevant blocks and formats them for
> > its own use, or if it barfs completely and just bails out complaining that
> > the partition does not contain UBI data. If the relevant blocks were
> > erased, then I think UBI would simply concede that the a previous erase
> > attempt had been prematurely aborted, and re-erase the blocks and write
> > its headers, so perhaps that is something to try. At any rate it involves
> > at least some mild trickery (erase the blocks that previously contained
> > jffs2 data).
> > 
> Yes, during mounting of UBIFS volumes, UBI checks for erase-header
> on first-page of every block. 

Mounting UBIFS volumes should not be a problem - the existing ones are
not located in the newly added area of the NAND.  The question however
is what the UBI layer itself does, if I for example try to create a
new volume which then would allocate blocks from the newly added
space.

> So, effectively you don't even need to erase the partition to convert
> it into UBI volume, you just try attaching it as UBI volume and UBI
> should erase it for you. (though flagging some warnings on the way).

Are you sure about that?

Well, I guess I'll have to try it out in the end...


Thanks!

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
"Deliver yesterday, code today, think tomorrow."

  reply	other threads:[~2013-10-09 15:06 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 [this message]
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
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=20131009150538.BAD57380432@gemini.denx.de \
    --to=wd@denx.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    --cc=ricard.wanderlof@axis.com \
    /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