Re: question about possibility of data loss in Ext2/3 file system

[Xin Zhao]

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@xxxxxxxxxxxxx> 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.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/