All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Charles Manning <manningc2@actrix.gen.nz>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS robustness questions
Date: Fri, 24 Jul 2009 09:03:28 +0300	[thread overview]
Message-ID: <4A694EB0.9040105@gmail.com> (raw)
In-Reply-To: <200907241600.54640.manningc2@actrix.gen.nz>

On 07/24/2009 07:00 AM, Charles Manning wrote:
> This is probably documented somewhere but I could not find it...
>
> What operations in UBIFS are robust to power failure and which are not?

Hi, did you look through these:

http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file

>
> I know for example that writing a file into flash does not mean it has been
> completely written to flash until after a sync, but what about other
> operations such as mv?
>
> The reasonn I'm asking this is that I want to be able to "hot-swap" a
> directory of files without losing any file state.

Err, if you do sync() and the like properly, you should not loose anything.

> What I'm considerings doing is something like:
>
> Start with ~/runtime having a sane set of files
>
> untar etc into ~/updated
> sync
> mv ~/updated ~/run-time
> sync
>
> What is unacceptable is that, at any time, a power failure/reboot results in
> ~/runtime having a non-sane set of files.

Err, this will just move "updated" to the "runtime" directory. Is this what
you mean? But the above must be safe.

> * Does the above sequence look safe?
> * Is the second sync required?

It is required if you want to make sure that the directory has really been renamed,
otherwise the renaming data will sit in the write-buffer for some time, and in case
of a power you end up with "updated" at the old place, but nothing should be
corrupted. IOW, you do not have to, but may want to.

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

  reply	other threads:[~2009-07-24  6:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-24  4:00 UBIFS robustness questions Charles Manning
2009-07-24  6:03 ` Artem Bityutskiy [this message]
2009-07-24  6:43 ` Adrian Hunter
2009-07-24  9:24   ` Adrian Hunter
2009-07-24 10:03     ` Adrian Hunter
2009-07-24 23:39       ` Jamie Lokier
2009-07-26  6:29         ` Adrian Hunter
2009-07-26 19:21           ` Jamie Lokier
2009-07-27  8:09             ` Adrian Hunter

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=4A694EB0.9040105@gmail.com \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=manningc2@actrix.gen.nz \
    /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.