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.
It is important to note that the copies provided by this feature are in
addition to any redundancy provided by the pool configuration or the
underlying storage. For example:
All of these examples seem to assume that there six disks.
* In a pool with 2-way mirrors, a filesystem with copies=1 (the default)
will be stored with 2 * 1 = 2 copies. The filesystem can tolerate any
1 disk failing without data loss.
* In a pool with 2-way mirrors, a filesystem with copies=3
will be stored with 2 * 3 = 6 copies. The filesystem can tolerate any
5 disks failing without data loss (assuming that there are at least
ncopies=3 mirror groups).
This one assumes best case scenario with 6 disks. Suppose you had 4 x
72 GB and 2 x 36 GB disks. You could end up with multiple copies on
the 72 GB disks.
* In a pool with single-parity raid-z a filesystem with copies=2
will be stored with 2 copies, each copy protected by its own parity
block. The filesystem can tolerate any 3 disks failing without data
loss (assuming that there are at least ncopies=2 raid-z groups).
C. MANPAGE CHANGES
*** zfs.man4 Tue Jun 13 10:15:38 2006
--- zfs.man5 Mon Sep 11 16:34:37 2006
***************
*** 708,714 ****
--- 708,725 ----
they are inherited.
+ copies=1 | 2 | 3
+ Controls the number of copies of data stored for this dataset.
+ These copies are in addition to any redundancy provided by the
+ pool (eg. mirroring or raid-z). The copies will be stored on
+ different disks if possible.
Any statement about physical location on the disk? It would seem as
though locating two copies sequentially on the disk would not provide
nearly the amount of protection as having them fairly distant from
each other.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
