IMO:
- The hardest problem in the case of bleaching individual files or
datasets is dealing with snapshots/clones:
- blocks not shared with parent/child snapshots can be bleached with
little trouble, of course.
- But what about shared blocks?
IMO we have two options:
a) Warn the user that some blocks remain unbleached;
b) Give the user an option to force bleaching shared blocks.
(b) Would break the snapshot read-only-ness, but it's better than
forcing the user to destroy clones and snapshots in order to
really bleach some sensitive content.
I'd say go for both, (a) and (b). Of course, (b) may not be easy to
implement.
- Unlink is not the right operation to bleach on!
That's because we don't have a fast dnode# -> path function (ncheck),
and we don't have path info for the unlinked file in the snapshots
and clones that share it (worse, they may have additional hard
links).
Instead I would propose a new bleach(1), bleach(2), VOP_BLEACH() and
fop_bleach() (with emulation in the fop for UFS and filesystems that
don't COW).
The new system call should either appear to truncate the file or to
overwrite it with zeros. The latter would allow for bleaching some
byte ranges, rather than the whole file (ZFS complexity: first COW
the non-bleached parts of blocks, then bleach the freed blocks).
- Bleaching vdevs is easier, of course, but the whole vdev has to be
bleached as by that point we've no knowledge of which blocks have
never been used.
Cheers,
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
