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 15:25:11 -0600
Cc: Russell Cattelan <cattelan@xxxxxxxxxxx>, Martin Steigerwald <Martin@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20081229201741.GA20024@xxxxxxxxxxxxxxxxxx>
References: <200812291920.34123.Martin@xxxxxxxxxxxx> <4959205E.4000000@xxxxxxxxxxx> <20081229192957.GC18092@xxxxxxxxxxxxxxxxxx> <49592E7D.4050208@xxxxxxx> <20081229201741.GA20024@xxxxxxxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
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.


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