Matthew Ahrens wrote:
Darren J Moffat wrote:
I believe that ZFS should provide a method of bleaching a disk or part
of it that works without crypto having ever been involved.
I see two use cases here:
1. This filesystem contains sensitive information. When it is freed,
make sure it's really gone.
I believe that the proper way to do this is to introduce a new zfs
property (say, "bleach") which, when set, will cause any blocks which
are freed to be bleached. The value of the property can specify the
type of bleach to use (ie, the overwrite pattern).
To ease administrative complexity, this property should probably only be
set at filesystem creation time (eg. 'zfs create -o
bleach=maximum-strength pool/fs'). Furthermore, 'zfs promote <fs>'
should not be run if the fs and its origin have different bleach
settings (because the ownership of the shared blocks would change).
However, clones do not in general pose any problems for this model
(because it's always clear which fs owns each block, and only that fs
can free it).
2. I've deleted some stuff at some point in the past, and now I want to
make sure that it's really gone.
To do this, we should have a "zpool bleach" command which would
immediately go and bleach all unallocated blocks.
Note that if both these features are implemented, it might make sense to
allow changing the 'bleach' property on a fs after it has been created,
and have that implicitly kick off a 'zpool bleach' to ensure that any
space previously used for that fs is bleached.
Also note that these bleaching features would not change the semantics
of snapshots, clones, etc. A block will not be bleached until all
references to it are removed, and the block is freed.
You have it in a nutshell as far as I'm concerned, nice simplification
that we only need this at the ZFS level and at the pool level.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
