>-Steve Lord [05 Dec 2001 11:20 -0600] wrote:
>
> 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
>
Thanks, Steve, it becomes much clear to me now as why it is. This
problem is critical to us as we run structure simulation for up
to several weeks and dump intermediate data every couple hours
and append them to few large files. If for some reason the system
crash during data output (though rarely), all the results from
few weeks running will gone which is unacceptable for us.
Probably I should looking for FS journaling both meta-data and
file-data, although I don't really need file-data journaling if
ever I could get my old content back.
Xianglong
--
Dept. Materials Science and Engineering
MIT, Room 13-4050
Cambridge, MA 02139
|