On Mon, Mar 17, 2014 at 3:35 AM, Dave Cottlehuber <d...@jsonified.com> wrote:

> On 17. März 2014 at 05:00:25, roemer (uwe.ro...@gmail.com) wrote:
> > > How does a 'copies=2' filesystem play together with a 'RAIDZ1' (or even
> > > RAIDZ2) pool? RAIDZ would have all data stored redundantly already, so
> > would 'copies=2' not end up in quadrupling the storage requirement if
> used
> > > on a raidz pool?

> Yes

No, RAIDZ does not store your data redundantly. It splits your data across
multiple drives and uses space equivalent to one drive to store parity
information about the data so that it can be mathematically made whole if
one drive goes missing. RAIDZ2 or RAIDZ3 just raise the level of parity,
i.e. the number of disk failures that can happen before data is lost, to
two or three respectively.

So the amount of space lost to parity is a constant of disk size x RAID
level. Thus, if you're using copies, the amount of space lost is just
dataset size / copies. One of the nice things about using copies as opposed
to mirroring is that you can set it on a per file system (e.g. dataset) as
opposed to mirroring which affects the entire vdev.

On the other hand, if you're using mirroring, then yes turning on copies=2
does cut your storage space to pool size / 4. (Assuming all datasets in the
pool have this set.)

RAIDZ vs mirroring vs copies all comes down to trading off performance vs
Reliability, Availability and Serviceability vs space. There are formulas
for figuring all of this out. Start at Serve the Home's Raid Reliablitity
takes into account everything, but increasing file redundancy. For that
there's this article: ZFS, Copies, and Data
And for RAIDZ vs Mirroring performance see When To (And Not To) Use


* Note that the Mean Time to Data Loss calculated at this site, while being
an industry standard, is essentially useless other than for getting a
relative comparison of different configurations. For details see: Mean time
to meaningless: MTTDL, Markov models, and storage system


You received this message because you are subscribed to the Google Groups 
"zfs-macos" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to zfs-macos+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to