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

From: Russell Cattelan <cattelan@thebarn.com>
To: Chris Wedgwood <cw@f00f.org>
Cc: Martin Steigerwald <Martin@Lichtvoll.de>,
	Russell Cattelan <cattelan@thebarn.com>,
	xfs@oss.sgi.com
Subject: Re: massively truncated files with XFS with sudden power loss on 2.6.27 and 2.6.28
Date: Mon, 29 Dec 2008 14:09:33 -0600	[thread overview]
Message-ID: <49592E7D.4050208@xfs.org> (raw)
In-Reply-To: <20081229192957.GC18092@puku.stupidest.org>

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs