[Top] [All Lists]

Re: Atomicity of xfs_fsr -- also isolation?

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Atomicity of xfs_fsr -- also isolation?
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 16 Feb 2005 07:00:43 -0600
In-reply-to: <20050216101917.GA21891@xxxxxxxxxxxxxxxxxxxxx>
References: <87ll9obz2e.fsf@xxxxxxxxxxxxx> <20050216101917.GA21891@xxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 0.9 (X11/20041127)
martin f krafft wrote:
also sprach Florian Weimer <fw@xxxxxxxxxxxxx> [2005.02.16.1104 +0100]:

Is it safe to run xfs_fsr on a file which is regularly updated?  It
seems that if a copy is made and later linked as the original, updates
to the file might be lost.  Is this really the case?

It does say "in an atomic manner", leading me to believe that
updates to the file are not going to get in the way.

xfs_fsr stats the original inode, allocates a new inode and space,
it then copies the contents of the first inode over to the second

A special call is then used to flip the extents of the two inodes,
if and only if the first inode has not changed in any way - this
check is performed inside the special call using the stat info
from the start of the run. This test is done after the inode is
locked - there must also be no other reference to the inode at
the time and no cached dirty state. If any of these tests fail,
the new inode and data are thrown away. If the extent flip
succeeds, then the new inode and the old extents are freed.

I cannot remember the exact details on the test conditions used
in the extent flip logic, but it is designed to abort the
defragment if anything about the original inode has

This does mean if a large file is being updated all the time,
it is pretty hard to defragment it.


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