xfs
[Top] [All Lists]

Re: massively truncated files with XFS with sudden power loss on 2.6.27

To: Chris Wedgwood <cw@xxxxxxxx>
Subject: Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Mon, 29 Dec 2008 14:09:33 -0600
Cc: Russell Cattelan <cattelan@xxxxxxxxxxx>, Martin Steigerwald <Martin@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20081229192957.GC18092@xxxxxxxxxxxxxxxxxx>
References: <200812291920.34123.Martin@xxxxxxxxxxxx> <4959205E.4000000@xxxxxxxxxxx> <20081229192957.GC18092@xxxxxxxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
Chris Wedgwood wrote:
On Mon, Dec 29, 2008 at 01:09:18PM -0600, Russell Cattelan wrote:

The question that I have is regards to kde apps.

i just did a quick strace of something, i see it do:


open newfile
write data
close file
rename newfile over oldfile

no fsync before close...
Hmm that is worse than truncate to 0, since now we have a new file vs one that has been truncated.
But really same net result.
Still why is the file size making it to disk before the data and more importantly the extent transaction to the log?
that should have been fixed.


this will bite xfs more than ext3 w/ ordered mode
Delayed allocation is a factor (and this will be true of any fs supporting delayed allocation) holding of data flushes helps reduce fragmentation by allowing larger segments to be flushed out, but it increases the time data is held in cache and thus create a larger window for data loss.

-Russell

<Prev in Thread] Current Thread [Next in Thread>