Re: [RFC] extent whiteouts

[Andreas Dilger <adilger@clusterfs.com>]

Did anyone ever see this?

This is a relatively simple (and actually safe) change to make now, but
would be harder to do as ext4 becomes more widely used.

I think all that would be needed is that when accessing an extent with
ext_pblock() (ee_start | ee_start_hi) == 0 we return zeroes, just as if
reading from an uninitialized extent or hole.  When allocating to this
extent we treat the ee_start == 0 extent similar to an uninitialized
extent, in that it needs to be split and can't merge with neighbour extents.

On May 14, 2007  17:08 -0600, Andreas Dilger wrote:
> For snapshot filesystems and in some cases where it is expected to do tree
> rebalancing it would be desirable to allow a "whiteout" for an extent.  That
> means the extent would be present in the tree, and would explicitly list
> the data blocks as a "hole" (i.e. ee_start == 0).  This is useful because
> it avoids the need to search all of the "backing" inodes to see if there is
> allocated data, and it also handles the case where the new file is truncated
> and extended (leaving a hole) but there is still data in the backing file.
> 
> Since block == 0 is not a valid data for ext3 it should never happen,
> and if it ever did happen it would be better to return all zeros (and
> not allow writing to the extent) instead of overwriting the superblock).
> 
> This would need some special casing in the extent code, but it probably
> would not be much different than what is currently the case for preallocated
> extents, and it would be a good time to add this in along with the
> preallocated extents.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.