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 15:25:11 -0600	[thread overview]
Message-ID: <49594037.9070201@xfs.org> (raw)
In-Reply-To: <20081229201741.GA20024@puku.stupidest.org>

Chris Wedgwood wrote:
> On Mon, Dec 29, 2008 at 02:09:33PM -0600, Russell Cattelan wrote:
>
>   
>> Still why is the file size making it to disk before the data and
>> more importantly the extent transaction to the log?
>>     
>
> well, as you know, it's logged, the data isn't
>   
yes but the whole deal with null files is no extents for a file size 
that should have extents.

So if the extent creation transaction is logged then it should be safe 
to update the file size on disk,
if not then the file "last flushed" size should be on disk. In this case 
I would assume 0, since that would
be the last valid flush size.

>   
>> that should have been fixed.
>>     
>
> the window was shrunk to write out begins on close for existing files
> the are opened with truncate (i think nathans did that some time
> ago?)
>   
correct but that change/hack has apparently been removed at some point? 
maybe along with the "last flush size" changes?

> new files won't be affected by that change
>   
Correct even if the sync on close if truncate code was there it would 
not help kde apps apparently.

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