On Thu, Dec 21, 2006 at 03:31:59PM +0000, Darren J Moffat wrote: > 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!
Yes, bleaching lazily would help with performance. You might even delay bleaching for very long periods of time if you want, as long as there's an interface by which to request that all outstanding free-but-not-yet- bleached blocks be bleached immediately and synchronously. > >I for one would prefer encryption, which may turns out to be > >much faster than bleaching and also more secure. > > At least NIST, under I believe the guidance of the NSA, does not > consider that encryption and key destruction alone is sufficient in all > cases. Which is why I'm proposing this as complementary. James makes a good argument that this scheme won't suffice for customers who need that level of assurance. I'm inclined to agree. For customers who don't need that level of assurance then encryption ought to suffice. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
