David Bustos wrote:
Quoth Darren J Moffat on Thu, Dec 21, 2006 at 03:31:59PM +0000:
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be soooo expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system modification... Heh, well, if privacy of
your data is important enough, you probably don't care too much about
performance.
I'm not sure it will be that slow, the bleaching will be done in a
separate (new) transaction group in most (probably all) cases anyway so
it shouldn't really impact your write performance unless you are very
I/O bound and already running near the limit. However this is
speculation until someone tries to implement this!
Bleaching previously used blocks will corrupt files pointed to by older
uberblocks. I think that means that you'd have to verify that the new
uberblock is readable before you proceed, since part of ZFS's fault
tolerance is falling back to the most recent good uberblock if the
latest one is corrupt. I don't think this makes bleaching unworkable,
but the interplay will require analysis.
Of course. I didn't mention it because I thought it was obvious but
this would NOT break the COW or the transactional integrity of ZFS.
One of the possible ways that the "to be bleached" blocks are dealt with
in the face of a crash is just like everything else - they would be in
the ZFS Intent Log as "things to do".
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
