On Tue, Sep 12, 2006 at 10:36:30AM +0100, Darren J Moffat wrote: > Mike Gerdts wrote: > >Is there anything in the works to compress (or encrypt) existing data > >after the fact? For example, a special option to scrub that causes > >the data to be re-written with the new properties could potentially do > >this. If so, this feature should subscribe to any generic framework > >provided by such an effort. > > While encryption of existing data is not in scope for the first ZFS > crypto phase I am being careful in the design to ensure that it can be > done later if such a ZFS "framework" becomes available. > > The biggest problem I see with this is one of observability, if not all > of the data is encrypted yet what should the encryption property say ? > If it says encryption is on then the admin might think the data is > "safe", but if it says it is off that isn't the truth either because > some of it maybe in encrypted.
I agree -- there needs to be a filesystem re-write option, something like a "scrub" but at the filesystem level. Things that might be accomplished through it: - record size changes - compression toggling / compression algorithm changes - encryption/re-keying/alg. changes - checksum alg. changes - ditto blocking What else? To me it's important that such "scrubs" not happen simply as a result of setting/changing a filesystem property, but it's also important that the user/admin be told that changing the property requires scrubbing in order to take effect for data/meta-data written before the change. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
