public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Static UBI volumes and ubiupdatevol ?
Date: Thu, 16 Dec 2010 18:26:15 +0200	[thread overview]
Message-ID: <1292516775.2364.108.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.1012151129250.7024@lnxricardw.se.axis.com>

On Wed, 2010-12-15 at 11:43 +0100, Ricard Wanderlof wrote:
> I'm also wondering if anyone has any thoughts on upgrading a 'live' 
> system, when the flash is managed by UBI.
> 
> With a system based on mtd+jffs2 it is actually possible to reflash the 
> partition with the [read only] root file system on it without unmounting, 
> as long as no accesses are made to the physical flash during the rewrite 
> or afterwards. In other words, immediately after reflashing the system 
> must be rebooted.

Hmm, I presume you can do this with UBIFS, but you need to make sure all
the backgound stuff like moving and eraseing eraseblocs is done before
doing this by doing fsync() on your /dev/ubiX_Y device (UBI volume
character device), see the 'vol_cdev_fsync()' function. Ah, and of
course you need to sync UBIFS before this.

Then if you can guarantee that no one is reading writing to it, you can
change the flash.

Another option is to remount R/O, if you can make sure there are no
processes keeping files open in R/W mode.

> However, with UBI, given that there are background threads which might be 
> doing garbage collection etc I'm suspecting such a solution might not be 
> as suitable when the flash is managed by UBI. Or is there a some solution 
> that someone has tried with any level of success?

Just call sync(), then fsync on the UBI volume, and you won't have
background processes if there is not I/O.

Be beware, even reading from UBIFS can cause scrubbing in UBI.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2010-12-16 16:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-15  8:06 Static UBI volumes and ubiupdatevol ? Ricard Wanderlof
2010-12-15 10:43 ` Ricard Wanderlof
2010-12-16 16:26   ` Artem Bityutskiy [this message]
2010-12-17  9:39     ` Ricard Wanderlof
2010-12-17 13:04       ` Artem Bityutskiy
2010-12-17 15:02         ` Ricard Wanderlof
2010-12-17 17:05           ` Artem Bityutskiy
2010-12-29 20:26           ` Russ Dill
2010-12-16 16:19 ` Artem Bityutskiy
2010-12-17  9:33   ` Ricard Wanderlof
2010-12-17 12:26     ` Artem Bityutskiy
2010-12-17 12:31       ` Ricard Wanderlof
2010-12-17 12:40         ` Artem Bityutskiy

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=1292516775.2364.108.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --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