On Mon, 2006-12-18 at 16:05 +0000, Darren J Moffat wrote:
> 6) When modifying any file you want to bleach the old blocks in a way
> very simlar to case 1 above.
I think this is the crux of the problem. If you fail to solve it, you
can't meaningfully say that all blocks which once contained parts of a
file have been overwritten and instead have to fall back on a "bleach
all unallocated blocks in the pool".
And if you can solve this one, I think you get cases 1 and 2 "for free".
I think the way to go here is to create a file, dataset, and/or pool
property which turns on "bleach on free"; any blocks freed after this
property set will be appropriately bleached.
Other issues:
- in some threat models, overwrite by zero is sufficient; in others,
you need multiple passes of overwrite with specific data patterns.
- If you're going to immediately reuse a block, do you need to bleach
before reallocation, or is mere overwrite by different allocated data
considered sufficient?
There also may be a reason to do this when confidentiality isn't
required: as a sparse provisioning hack..
If you were to build a zfs pool out of compressed zvols backed by
another pool, then it would be very convenient if you could run in a
mode where freed blocks were overwritten by zeros when they were freed,
because this would permit the underlying compressed zvol to free *its*
blocks.
- Bill
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
