linux-ext4 - Re: [RFC] extent whiteouts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 19 Jun 2007 02:14:04 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	linux-ext4@...r.kernel.org
Cc:	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>
Subject: Re: [RFC] extent whiteouts

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html