[Top] [All Lists]

Re: Questions about recovery

To: Steve Lord <lord@xxxxxxx>
Subject: Re: Questions about recovery
From: Andi Kleen <ak@xxxxxxx>
Date: Thu, 17 May 2001 16:55:23 +0200
Cc: Eric Sandeen <sandeen@xxxxxxx>, Lauri Ojantakanen <lauri@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <200105171447.f4HElu921491@jen.americas.sgi.com>; from lord@sgi.com on Thu, May 17, 2001 at 09:47:56AM -0500
References: <sandeen@sgi.com> <200105171447.f4HElu921491@jen.americas.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
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 probably
> 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 call
> 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]


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