Bob Friesenhahn wrote:
On Wed, 11 Nov 2009, Darren J Moffat wrote:
note that "eradication" via overwrite makes no sense if the underlying
storage uses copy-on-write, because there's no guarantee that the newly
written block actually will overlay the freed block.
Which is why this has to be a ZFS feature rather than something link
GNU shred(1) which runs in userland.
Zfs is absolutely useless for this if the underlying storage uses
copy-on-write. Therefore, it is absolutely useless to put it in zfs. No
one should even consider it.
I disagree. Sure there are cases where ZFS which is copy-on-write is
sitting ontop of something that is copy-on-write (iSCSI luns backed by
ZFS on another system for example) that doesn't mean there are no cases
where this is useful. For example in an appliance or other controlled
environment it isn't useless and it is being considered for example
those use cases of ZFS.
If we introduce this for ZFS it would likely be a per dataset or pool
property and it will be documented that the whole storage stack needs to
be taken into consideration for it to determined if this is actually
effective.
The use of encrypted blocks is much better, even though encrypted blocks
may be subject to freeze-spray attack if the whole computer is
compromised while it is still running. Otherwise use a sledge-hammer
followed by incineration.
Much better for jurisdictions that allow for that, but not all do. I
know of at least one that wants even ciphertext blocks to overwritten.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
