xfs
[Top] [All Lists]

Re: Zero filled files

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: Zero filled files
From: Steve Lord <lord@xxxxxxx>
Date: 13 May 2003 10:50:45 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20030513154629.GD26769@xxxxxxxxxxxxx>
Organization:
References: <20030512102338.GA3268@xxxxxxxxxxxxxxx> <1052742135.1173.1.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20030513053133.GG10596@xxxxxxxxxxxxx> <1052839608.22728.104.camel@xxxxxxxxxxxxxxxxxxxx> <20030513154629.GD26769@xxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Tue, 2003-05-13 at 10:46, Andi Kleen wrote:
> On Tue, May 13, 2003 at 10:26:49AM -0500, Steve Lord wrote:
> > Complete change in approach is the short answer.
> 
> Nice. 
> 
> > By adding the periodic actvity thread we activate some code which
> > looks for an empty AIL and writes out a dummy log record to record
> > the new tail of the log.
> 
> Does it check that it already wrote the marker before writing again ? 
> If not the laptop users will hate you ;)

It does it twice, then stops

> 
> > 
> > There are still windows when zero filled files are possible, as the
> > updated inode size can make it out to disk in a transaction before
> > all the extents do. Doing the 100% solution will require some brain
> > cells.
> 
> And I imagine changing this could add lots of seeking ...
> (between the inode areas and the data areas) 

It may be more along the lines of holding off on letting the inode
out to disk, but it would be complex.

Steve

> 
> > I can say though, that after sync returns a linux xfs filesystem is
> > now on disk to the point where it will look the same after a reboot.
> 
> That should fix the number 1 complaint about XFS yes.
> 
> Thanks for the explanation,
> -Andi
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


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