> From: blymn@awadi.com.AU (Brett Lymn)
> Date: Mon, 31 Oct 1994 12:52:13 +1030 (CST)

> >It was written in one article:
> >>As someone pointed out, the only way to ensure file system integrity is to
> >>write out first data blocks, then indirect blocks and then the inode. FFS
> >>does the opposite which is at best useless, at worst wrong.
> >
> >(This is supposed to be the way linux does it)
> >
> >How can this model be better then the opposite .
> >I would think that it mainly were a question of locking the datablocks, 
> >
> 
> This depends - it depends on whether or not you want to know that your
> file system has been damaged.  Updating the inode last is only going
> to mean that getting dangling file pointers is less likely it does not
> really add to the robustness of the fs.  Personally, I would like to
> know when my fs is broken and that it needs fixing rather than have
> things just quietly not be there.  If you consider this scenario:  the
> data blocks are written but before the inodes are updated the power
> dies.  How are you better off?  The data is somewhere on the disk - if
> you were really persistent you could find it, maybe, but it is no
> worse than having a dangling ref.

You are better off in that the only recovery work needed is to link
the inode somewhere (free, or in lost+found).  You know that if the
file exists (in its correct location) then it contains valid data.

If you write the inode first and it has dangling references, how can
you tell?  How do you know if it has garbage in it or not?

Gordon Ross