public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Xin Zhao <uszhaoxin@gmail.com>
Cc: Sam Vilain <sam@vilain.net>, "Theodore Ts'o" <tytso@mit.edu>,
	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: Tue, 28 Feb 2006 11:56:39 -0500	[thread overview]
Message-ID: <440480C7.50507@cfl.rr.com> (raw)
In-Reply-To: <4ae3c140602262338u2666319vc6401e32257b3543@mail.gmail.com>

Xin Zhao wrote:
> Many thanks for above responses.
> 
> Sounds like Ext3 uses journal to protect the data integrity. In data
> journal mode, ext 3 writes data to journal first, marks start to
> commit, then marks "done with commit" after data is flushed to disk. 
> If power failure happen during data flush, the system will redo the
> data writes next time system is back.
> 
> However, how to guarantee the integrity of journal? This solution
> works based on an assumption that the journal data has been flushed to
> disk before file data is flushed. Otherwise, consider this scenario:

The kernel flushes the writes to the journal before it starts writing to 
the main area of the disk, then marks the transaction as complete only 
after the actual updates have been flushed.

> process A wrote a data block to File F. Ext3 first writes this data
> block into journal, put a "start to commit" notice, flags that journal
> page as dirty. (note that the journal data is not flushed into disk
> yet). Then ext3 starts to flag data page as dirty and wait for flush
> daemon to write it to disk. Say just when the disk controller writes
> 2048 out of 4096 bytes into disk, power outage happens. At this time,
> journal data has not been flushed into disk, so no enough information
> to support redo. The file A will end up with some junk data. So
> flushing journal data to disk before starting to write file data to
> disk seems to be necessary. If so, how ext3 guarantees that? Is it
> because the dirty pages are flushed in a first come first serve
> fashion?
> 
> Another concern is that the journal data mode requires twice as much
> as data to write, this could impact performance if disk bandwidth
> usage is over 50%. For small files, it could be rare to use 50%. But
> how about large files?  In a real world system,  what's the probablity
> of using over 50% disk bandwidth?
> 

Depending on exactly what you are doing it will be anywhere from 0 to 
100%.  It entirely depends on the hardware you have and the tasks you 
are asking it to perform.  For most people though, the performance hit 
is too high, and it really doesn't 100% prevent data loss because 
programs writing to a file do not inform the kernel about when a 
transaction should start or stop, so it has to guess.

Programs that are mission critical will use their own mechanism to 
prevent corruption of their data files rather than rely on data 
journaling.  Usually this results in better safety and efficiency.

> I am sorry for ask for too high integrity on data. But I think ext3 is
> a famous stable file system, it should have some good design to
> protect data integrity.
> 

Which is why it does.

> Last question, does anyone know whether it is possible that ext3
> creates some junk data or makes bitmap and inode inconsistent (under
> any extreme condition) ?
> 

No.

> Again, thanks for your help!
> 
> Xin
> 


  reply	other threads:[~2006-02-28 16: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
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 [this message]
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=440480C7.50507@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=arjan@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@vilain.net \
    --cc=tytso@mit.edu \
    --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