From: Chris Mason <chris.mason@oracle.com>
To: Josef Bacik <josef@redhat.com>
Cc: Jakob Unterwurzacher <jakobunt@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Rename+crash behaviour of btrfs - nearly ext3!
Date: Mon, 17 May 2010 16:09:12 -0400 [thread overview]
Message-ID: <20100517200912.GE8635@think> (raw)
In-Reply-To: <20100517192554.GB2322@localhost.localdomain>
On Mon, May 17, 2010 at 03:25:54PM -0400, Josef Bacik wrote:
> On Mon, May 17, 2010 at 08:04:21PM +0200, Jakob Unterwurzacher wrote:
> > Hi!
> >
> > Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
> > solve them all. And it nearly does! Now I wonder if the remaining 0.2
> > seconds window of exposing 0-size files could be closed too.
> >
> > I tested using two simple scripts (attached for reference) on kernel
> > 2.6.34-rc7:
> > - rentest creates files $i.tmp and renames to $i.cur,
> > - owtest does the same but overwrites existing $i.cur files,
> > letting them run for 30-50 seconds then resetting the virtual machine.
> >
> > The results for ext3 are as expected: 0-size files are never exposed as
> > $i.cur, overwrites are atomic.
> >
> > ext4 overwrites are /almost/ atomic (I get one 0-size file in owtest),
> > lots of 0-size files are exposed in rentest (30 seconds window).
> >
> > btrfs *nearly* does as well as ext3. Overwrites are atomic.
> >
> > The rentest exposes only a 0.2 seconds windows of 0-size $i.cur files,
> > so that a "ls --full-time" after the crash looks like this (notice the
> > time between 01281.cur and 01292.tmp, only 0.2 seconds):
> > [...]
> > -rw-r--r-- 1 root root 20 2010-05-17 17:06:25.812016407 +0200 01280.cur
> > -rw-r--r-- 1 root root 20 2010-05-17 17:06:25.835999490 +0200 01281.cur
> > -rw-r--r-- 1 root root 0 2010-05-17 17:06:25.868035485 +0200 01282.cur
> > [...]
> > -rw-r--r-- 1 root root 0 2010-05-17 17:06:26.080003626 +0200 01291.cur
> > -rw-rw-rw- 1 root root 0 2010-05-17 17:06:26.108010083 +0200 01292.tmp
> >
>
> This isn't actually true. There is no window, the inode isn't written to disk
> until all of the data is flushed to disk. So the in memory inode will be
> update, and therefore show an i_size of 0 since the io hasn't finished, but if
> you were to crash at this point, when you came back up you'd have the old data
> in place because the new inode data wasn't written to disk. I have a feeling
> ext4 is the same way, but I'd have to check for sure. Thanks,
Jacob, could you please confirm if your test includes a crash?
-chris
next prev parent reply other threads:[~2010-05-17 20:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-17 18:04 Rename+crash behaviour of btrfs - nearly ext3! Jakob Unterwurzacher
2010-05-17 19:12 ` Ric Wheeler
2010-05-17 19:25 ` Josef Bacik
2010-05-17 20:09 ` Chris Mason [this message]
2010-05-17 20:30 ` Jakob Unterwurzacher
2010-05-17 19:36 ` Chris Mason
2010-05-18 0:14 ` Jakob Unterwurzacher
2010-05-18 0:30 ` Chris Mason
2010-05-18 0:59 ` Chris Mason
2010-05-18 12:03 ` Jakob Unterwurzacher
2010-05-18 13:13 ` Chris Mason
2010-05-18 13:28 ` Oystein Viggen
2010-05-18 14:47 ` Thomas Bellman
2010-05-18 13:39 ` Aidan Van Dyk
2010-05-18 14:06 ` Jakob Unterwurzacher
2010-05-18 14:36 ` Chris Mason
2010-05-18 15:57 ` Jakob Unterwurzacher
2010-05-18 16:10 ` Chris Mason
2010-05-18 18:01 ` Goffredo Baroncelli
2010-05-18 18:24 ` Jakob Unterwurzacher
2010-05-18 23:00 ` Ric Wheeler
2010-05-19 1:05 ` Bruce Guenter
2010-05-19 1:34 ` Andy Lutomirski
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=20100517200912.GE8635@think \
--to=chris.mason@oracle.com \
--cc=jakobunt@gmail.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).