From: Artem Bityutskiy <dedekind@infradead.org>
To: Hamish Moffatt <hamish@cloud.net.au>
Cc: linux-mtd@lists.infradead.org
Subject: Re: ubifs version 1 compatibility
Date: Tue, 31 Mar 2009 09:23:38 +0300 [thread overview]
Message-ID: <1238480618.20906.6.camel@localhost.localdomain> (raw)
In-Reply-To: <20090326131550.GA15665@cloud.net.au>
On Fri, 2009-03-27 at 00:15 +1100, Hamish Moffatt wrote:
> On Thu, Mar 26, 2009 at 02:12:05PM +0200, Artem Bityutskiy wrote:
> > On Thu, 2009-03-26 at 23:04 +1100, Hamish Moffatt wrote:
> > > On Thu, Mar 26, 2009 at 11:50:23AM +0200, Artem Bityutskiy wrote:
> > > > On Thu, 2009-03-26 at 18:44 +1100, Hamish Moffatt wrote:
> > > > makes it very difficult to turn old image into new one. This will
> > > > basically mean we need:
> > > >
> > > > 1. extract files from the old image
> > > > 2. feed them to mkfs.ubifs.
> > > >
> > > > > Maybe before upgrade we could run mkfs.ubifs using the contents of the
> > > > > existing volume to create the new format, unmount it and ubiupdatevol it..
> > > >
> > > > The easiest way to do this is to boot the old kernel,
> > > > e.g. in vmware, extract the files using the nandsim technique:
> > > > http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_nandsim
> > > >
> > > > then feed them to mkfs.ubifs.
> > >
> > > Well I have these files on embedded devices out in the real world. The
> > > volume is storing user data, so I need to do this change in-place.
> >
> > Let me make sure I understand the need.
> >
> > So you have devises with v1 format in the wild. You want to upgrade
> > those devices. While upgrading, you will re-write some UBI volumes, but
> > after upgrade the user-data volume should contains exactly the same data
> > as before the upgrade, right?
>
> Yes, that's what I need.
I see. Well, because most of the UBIFS functionality is in the
kernel, it might probably be possible to teach the kernel UBIFS
implementation to automatically re-format the file-system if it
finds v.1 layout. However, this is not a very simple task, and
I am not sure I have time to implement this, sorry :-(
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
prev parent reply other threads:[~2009-03-31 6:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 5:15 ubifs version 1 compatibility Hamish Moffatt
2009-03-26 6:02 ` Artem Bityutskiy
2009-03-26 6:34 ` Artem Bityutskiy
2009-03-26 7:44 ` Hamish Moffatt
2009-03-26 9:50 ` Artem Bityutskiy
2009-03-26 12:04 ` Hamish Moffatt
2009-03-26 12:12 ` Artem Bityutskiy
2009-03-26 13:15 ` Hamish Moffatt
2009-03-31 6:23 ` Artem Bityutskiy [this message]
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=1238480618.20906.6.camel@localhost.localdomain \
--to=dedekind@infradead.org \
--cc=hamish@cloud.net.au \
--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 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.