All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Jean-Francois Landry <jflandry@atou.qc.ca>
Cc: Toby Dickenson <tdickenson@geminidataloggers.com>,
	reiserfs-list@namesys.com
Subject: Re: integrity question
Date: 28 May 2002 07:05:41 -0400	[thread overview]
Message-ID: <1022583941.22609.1251.camel@tiny> (raw)
In-Reply-To: <20020528022659.GA6451@atou.qc.ca>

On Mon, 2002-05-27 at 22:26, Jean-Francois Landry wrote:
> On Mon, May 27, 2002 at 10:35:24AM +0100, Toby Dickenson wrote:
> > On Sunday 26 May 2002 6:25 am, Jean-Francois Landry wrote:
> > 
> > thanks for your time,
> > 
> > >> 1. write to A/B/somefileX and fsync it
> > >> 2. mkdir A/C
> > >> 3. rename A/B/somefile to A/C/somefile
> > >> 4. rmdir A/B
> > >> 5. power loss
> > >>
> > >> I would like to guarantee that, after journal replay, 'somefile' is in
> > >> either of those two directories (or both). Am I correct to think that I
> > >> dont need any other syncs in there?
> > >
> > >You are correct, renames are atomic on journalling filesystems.
> > >So, no problems with half-written directory entries, if you lose power
> > >at the wrong time the journal replay procedure will throw the
> > >transaction out and you end up as if you never issued a rename at all.
> > 
> > Atomic rename isnt quite enough in the scenario I described. The filesystem 
> > also needs to take care that the step 3 is not committed before step 2, and 
> > that step 4 is not committed before step 3.
> 
> AFAIK, all transactions are written to the journal in the order they
> were issued, so this problem won't arise.

Correct.  Only data blocks can be written out of order, but the fsync
protects you from that.

-chris



      reply	other threads:[~2002-05-28 11:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-25 19:43 integrity question Toby Dickenson
2002-05-26  5:25 ` Jean-Francois Landry
2002-05-27  9:35   ` Toby Dickenson
2002-05-28  2:26     ` Jean-Francois Landry
2002-05-28 11:05       ` Chris Mason [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=1022583941.22609.1251.camel@tiny \
    --to=mason@suse.com \
    --cc=jflandry@atou.qc.ca \
    --cc=reiserfs-list@namesys.com \
    --cc=tdickenson@geminidataloggers.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 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.