linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Xin Zhao" <uszhaoxin@gmail.com>
To: "Arjan van de Ven" <arjan@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: question about possibility of data loss in Ext2/3 file system
Date: Wed, 22 Feb 2006 17:34:33 -0500	[thread overview]
Message-ID: <4ae3c140602221434v6ec583a7yf04df5fa7a4948fc@mail.gmail.com> (raw)
In-Reply-To: <1140645651.2979.79.camel@laptopd505.fenrus.org>

Apparently the scheme you described helps improve the file integrity.
But still not good enough. For example, if all data blocks are
flushed, then you will update the metadata. But right after you update
the block bitmap and before you update the inode, you lose power. You
will get some dead blocks.  Right? Do you know how ext2/3 deal with
this situation?

Also, the scheme you mentioned is just for new file creation. What
will happen if I want to update an existing file? Say, I open file A,
seek to offset 5000, write 4096 bytes, and then close. Do you know how
ext2/3 handle this situation?

Many thanks for your kind help!

Xin

On 2/22/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Wed, 2006-02-22 at 16:56 -0500, Xin Zhao wrote:
> > As far as I know, in Ext2/3 file system, data blocks to be flushed to
> > disk are usually marked as dirty and wait for kernel thread to flush
> > them lazily. So data blocks of a file could be flushed even after this
> > file is closed.
> >
> > Now consider this scenario: suppose data block 2,3 and 4 of file A are
> > marked to be flushed out. At time T1, block 2 and 3 are flushed, and
> > file A is closed. However, at time T2, system experiences power outage
> > and failed to flushed block 4. Does that mean we will end up with
> > getting a partially flushed file?  Is there any way to provide better
> > guarantee on file integrity?
>
> on ext3 in default mode it works a bit different
>
> if you write a NEW file that is
>
> then first the data gets written (within like 5 seconds, and not waiting
> for the lazy flush daemon). Only when that is done is the metadata (eg
> filesize on disk) updated. So after the power comes back you don't see a
> mixed thing; you see a file of a certain size, and all the data upto
> that size is there.
>
> If you need more guarantees you need to use fsync/fdata_sync from the
> application.
>
>
>

  reply	other threads:[~2006-02-22 22:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-22 21:56 question about possibility of data loss in Ext2/3 file system Xin Zhao
2006-02-22 22:00 ` Arjan van de Ven
2006-02-22 22:34   ` Xin Zhao [this message]
2006-02-22 23:07     ` Andreas Dilger
2006-02-23  4:58     ` Theodore Ts'o
2006-02-23 19:46       ` Sam Vilain
2006-02-24 16:29         ` Theodore Ts'o
2006-02-26 21:27           ` Sam Vilain
2006-02-27  7:38             ` Xin Zhao
2006-02-28 16:56               ` Phillip Susi
2006-02-23 12:52     ` linux-os (Dick Johnson)

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=4ae3c140602221434v6ec583a7yf04df5fa7a4948fc@mail.gmail.com \
    --to=uszhaoxin@gmail.com \
    --cc=arjan@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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).