linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Xin Zhao <uszhaoxin@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	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 23:58:36 -0500	[thread overview]
Message-ID: <20060223045836.GC9645@thunk.org> (raw)
In-Reply-To: <4ae3c140602221434v6ec583a7yf04df5fa7a4948fc@mail.gmail.com>

On Wed, Feb 22, 2006 at 05:34:33PM -0500, Xin Zhao wrote:
> 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?

Ext3 uses the journal to guarantee that the bitmap blocks are
consistent with the inode.  Ext2 will require that e2fsck be run to
fix the consistency problem.

> 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?

If you have a power failure right after the close, the data could be
lost.  This is true for pretty much all Unix filesystems, for
performance reasons.  If you care about the data hitting disk, the
application must use fsync().  

Regards,

						- Ted

  parent reply	other threads:[~2006-02-23  4:58 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
2006-02-22 23:07     ` Andreas Dilger
2006-02-23  4:58     ` Theodore Ts'o [this message]
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=20060223045836.GC9645@thunk.org \
    --to=tytso@mit.edu \
    --cc=arjan@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=uszhaoxin@gmail.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 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).