[dang, this thread started on the one week this quarter that I don't have
any spare time... please accept this one comment, more later...]
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.
This feature is similar to using mirroring, but differs in several
important ways:
* Mirroring offers slightly better redundancy, because one disk from
each mirror can fail without data loss.
Is this use of slightly based upon disk failure modes? That is, when
disks fail do they tend to get isolated areas of badness compared to
complete loss? I would suggest that complete loss should include
someone tripping over the power cord to the external array that houses
the disk.
The field data I have says that complete disk failures are the exception.
I hate to leave this as a teaser, I'll expand my comments later.
BTW, this feature will be very welcome on my laptop! I can't wait :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
