Darren J Moffat wrote:
Darren Reed wrote:
Hmmm, well, I suppose the same problem might apply to
encrypting data too...so maybe what I need is a zfs command
that will walk the filesystem's data tree, read in data and
write it back out according to the current data policy.
And if that file system is multiple terrabytes would you be okay with
there being a read and write lock while this runs ?
I am only guessing, but when encryption is "important enough" the answer is "yes."
But the next question is then "is this situation common enough to justify the effort."
The current plan is that encryption must be turned on when the file
system is created and can't be turned on later. This means that the
zfs-crypto work depends on the RFE to set properties at file system
creation time.
You also won't be able to turn crypto off for a given filesystem later
(because you won't know when all the data is back in the clear again and
you can safely destroy the key).
Why? Is the 'data is encrypted' flag only stored in filesystem metadata, or is
that flag stored in each data block? If the latter is true, it would be possible
(though potentially time-consuming) to determine which files are encrypted, and
which are not.
--------------------------------------------------------------------------
Jeff VICTOR Sun Microsystems jeff.victor @ sun.com
OS Ambassador Sr. Technical Specialist
Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
