Mike Gerdts wrote:
On 9/11/06, Matthew Ahrens <[EMAIL PROTECTED]> wrote:
B. DESCRIPTION
A new property will be added, 'copies', which specifies how many copies
of the given filesystem will be stored. Its value must be 1, 2, or 3.
Like other properties (eg. checksum, compression), it only affects
newly-written data. As such, it is recommended that the 'copies'
property be set at filesystem-creation time
(eg. 'zfs create -o copies=2 pool/fs').
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.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
