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. - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
