linux-ext4 - [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-next>] [day] [month] [year] [list]

Message-ID: <20070514230808.GA5581@schatzie.adilger.int>
Date:	Mon, 14 May 2007 17:08:08 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	linux-ext4@...r.kernel.org
Subject: [RFC] extent whiteouts

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