xfs
[Top] [All Lists]

Re: Developerworks XFS introduction.

To: Federico Sevilla III <jijo@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: Developerworks XFS introduction.
From: Seth Mos <knuffie@xxxxxxxxx>
Date: Wed, 16 Jan 2002 13:55:56 +0100 (CET)
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.44.0201162018271.9483-100000@gusi.leathercollection.ph>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Wed, 16 Jan 2002, Federico Sevilla III wrote:

> On Wed, 16 Jan 2002 at 07:40, Jeff Layton wrote:
> > > IBM developerWorks: Introducing XFS
> > > http://www-106.ibm.com/developerworks/library/l-fs9.html
> > Would anyone like to comment on the article? Steve L?
> 
> (I'm not Steve Lord but ...) I just read the article and everything seems
> to be in order. Nothing quite new (since I've been using XFS for awhile).
> However I really like how the NULL issue was explained. I never really
> looked at it that way (always saw it as a ... problem). And that bit
> quoting Steve Lord on a "coming soon" patch to improve delete performance
> was exciting. :)

Which will probably also fix the null issues.
If you opened a file in vi and then save the file it will create a new
file with the contents and delete the old file.
Deletes are synchronous and _will_ erase the old file and update the
metadata. Thus when power off occurs the data points to the new inode of
which the data was still in ram at that time.

So when deletes are asynchronous the delete will be commited at the same
time the new file data is written. This has the advantage that when the
box is powered off you loose the new data which is still in ram and the
delete is not commited. Thus preserving your old file.

Or that is my thought up theory based on previous posts on the list.

Cheers
Seth


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