|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|
|References:||<200812291920.34123.Martin@xxxxxxxxxxxx> <4959205E.4000000@xxxxxxxxxxx> <20081229192957.GC18092@xxxxxxxxxxxxxxxxxx>|
|User-agent:||Thunderbird 184.108.40.206 (Macintosh/20070728)|
Chris Wedgwood wrote:
Hmm that is worse than truncate to 0, since now we have a new file vs one that has been truncated.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...
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.
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.this will bite xfs more than ext3 w/ ordered mode
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28, Martin Steigerwald|
|Next by Date:||A rescue tool: xfs_irecover, Jan Engelhardt|
|Previous by Thread:||Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28, Chris Wedgwood|
|Next by Thread:||Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28, Eric Sandeen|
|Indexes:||[Date] [Thread] [Top] [All Lists]|