Subject: Re: Files on XFS not safe?!
From: Steve Lord <lord@sgi.com>
To: Xianglong Yuan <yuanx@mit.edu>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20011205120325.C3446@real-uma.mit.edu>
References: <20011205100043.A3437@real-uma.mit.edu>
	<Pine.LNX.4.33.0112051005510.26602-100000@chaos.egr.duke.edu>
	<20011205111421.B3446@real-uma.mit.edu>
	<1007569713.22718.10.camel@jen.americas.sgi.com> 
	<20011205120325.C3446@real-uma.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 05 Dec 2001 11:20:26 -0600
Message-Id: <1007572826.22679.16.camel@jen.americas.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 2001-12-05 at 11:03, Xianglong Yuan wrote:

> 
> I presume there is a log that has the information when the
> data-flashing is scheduled to start, whether it has done or not,
> and what the original file state (meta-data?) is. Now, if the
> system crashed before the data-flashing is done, could it be
> possible to trace the log back to the point before the unfinished
> data-flashing and give the original file state (meta-data?) back
> instead of the meta-data of the new file as it gives nothing?  (I
> believe the content of the old file is still on the disk and not
> zeroed by other program, and could be recovered if we know its
> locations (meta-data?).) Update the new meta-data only after a
> successful data-flashing.  Am I missing something here?

Writing file data out to disk in XFS does not go anywhere near the log,
only the allocation of extents goes in the log. Also, think about
what the editor is probably doing:

  o Create a new file with a temporary name
  o write all the file data into it.
  o remove the original file
  o rename the temporary file to the orginal name

How can the filesystem associate the two files with each other? It is
also this rename of the original file which is probably pushing the
inode out to disk with the new size. There must also be some operation
in there after the rename which is removing a file - and this is
a synchronous transaction - which is why the log is on disk at all.

Also, once we have removed extents from a file, it is very difficult to
work out which ones they were - and the xfs log is of fairly small size,
so there is always the possibility that the info is not even in the
log anymore.

We are working on removing the synchronous transactions, and this would
mean that there would be a chance the log write would not have been
issued to disk in this case and all we would see would be the original
file - as in the ext2 case where all of the pending metadata updates we
probably still in memory.

Steve

> 
> Xianglong
> 
>
-- 

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