From: David Woodhouse <dwmw2@infradead.org>
To: Piotr Trojanek <ptroja@elproma.com.pl>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Question about power fail during file upgrade
Date: Mon, 30 Sep 2002 09:38:51 +0100 [thread overview]
Message-ID: <1788.1033375131@redhat.com> (raw)
In-Reply-To: <20020930080233.GA1236@elproma.com.pl>
ptroja@elproma.com.pl said:
> On Thu, Sep 26, 2002 at 09:45:23AM +0100, David Woodhouse wrote:
> > Kschoo70C@netscape.net said:
> > > I need some help to understand how the JFFS2 works. If I have a
> > > version 1 of software component A on JFFS2, what happen if power
> > > failed while I am in the middle of upgrading the component A to
> > > version 2 ? The question is do I have version 1 intact or a
> > > combination of version 1 and 2 ?
> >
> > > Does the JFFS2 filesystem only set the inodes of a file to be valid
> > > only after a complete file is written to the flash ? Does the old
> > > file will only be deleted only after the new file is verified to be
> > > valid ?
> >
> > JFFS2 knows nothing of 'complete files'. You are guaranteed atomicity
> > of individual file system operations only, according to POSIX.
> >
> > As with other file systems, you can write the new version of the file,
> > then rename it over the top of the original. That will be atomic.
> >
> > There's been talk about extending JFFS2 to allow userspace
> > 'transactions' but it's not been done.
> so the only atomic change, that is guaranteed to work is renaming
> new.file -> old.file?
At the filesystem level, yes.
> if I need to make upgrade which depends on 10 files what should I do?
> how about put all filesystem in one .tar and put it in ramdisk at
> system startup, then make upgrade of .tar file, which is on JFFS2 DOC
> and reboot? will it work?
There are plenty of options, one of which is to implement transation
support in the file system so that your application can ensure that
either all 10 of your renames happen or none of them.
I'm assuming you only really care about atomicity w.r.t power failure, and
a moment where the files are absent is acceptable as long as they can be
trivially recovered at boot time? You could unpack all the files into a
directory -- '/usr/mypackage-v2', then make a symlink from /usr/mypackage
to whichever version is current. If you boot and find no symlink, you check
which is the most recent _intact_ version and symlink to that. Many
variations on the theme are possible.
trivially be re
--
dwmw2
prev parent reply other threads:[~2002-09-30 8:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-26 8:38 Question about power fail during file upgrade Kschoo70C
2002-09-26 8:45 ` David Woodhouse
2002-09-30 8:02 ` Piotr Trojanek
2002-09-30 8:38 ` David Woodhouse [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=1788.1033375131@redhat.com \
--to=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ptroja@elproma.com.pl \
/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