> On Thu, May 17, 2001 at 09:47:56AM -0500, Steve Lord wrote:
> > I should also add here that the difference between what happens with XFS in
> > this scenario and what would happen with ext2 is that with ext2 you probabl
> > would not see the new file at all - or the old one, but it depends on what
> > got synced and what did not. The reason files show up with no data in xfs
> > is that the delayed allocation code which reserves space during a write cal
> > has to bump the inode size - this size is making it out to disk, however,
> > the allocation of real extents and the flush of the data is not. If delayed
> > allocation was not being used you would get a file with garbage read off
> > the disk, since the disk space would be allocated during the write call,
> > but the data would still not be written out into it.
> It would be nice if there was at least an mount option to truncate
> the files in this case to the size without the unwritten extent.
> The people here seem to object to the zeroes ("garbage") in the holes,
> and I guess they would be more happy with truncated files.
> [I realize that it's somewhat hard to implement as it would need to keep
> a list somewhere about files that are candidates for such truncation; similar
> to the delete-on-recovery list needed for close after unlink]
Hey, you have the code.... ;-)
I suspect a simpler method of doing this would be keep size extensions
to the file which are only delayed allocate in an in memory only inode
size, the size synced out to disk or recorded in transactions would
reflect where the last real extent was written out to. You do have to
be careful though, since it is legal to have a hole at the end of a file
it is only when you do delalloc writes that this in memory size would
differ from the on disk one. The end result would be that after recovery
the size would return to the last one pushed out to disk - which would
tend to represent where there was real data in the file not zeros.