This make sense. Given set of devices, ZFS can only write to free blocks. If the only free blocks are close together or on the same dev, then the protection can't be as great. This is quite likely to happen on a fullish disk. copies > 1, however, is still better than none (a single dropped block in the right place can wreak havoc).
I personally like to use the 'copies' feature on machines where allocation priority for devices is for my storage pool, rather than my root pool. I like the idea that I can have multiple copies of blocks on my (single) boot device. This also work nicely because on a Solaris machine with lots of memory, I don't have to write to the disk much after boot, so the performance penalty seems fairly small. I have this running right now in one case. When I get the ability to mirror my rpool, I can remove the copies property if I wish. One other important caveat is that zfs properties only apply to newly-written data. So setting copies > 1 after an install won't make copies of the blocks you did the initial install to, just the block written going forward. cheers, Blake On Mon, Jan 19, 2009 at 1:04 AM, Carson Gaspar <car...@taltos.org> wrote: > Bob Friesenhahn wrote: >> On Sun, 18 Jan 2009, Tim wrote: >> >>> Honestly, I believe this list... when other people have asked if they can >>> use the copies= to avoid mirroring everything. I can't say I've saved any >>> of the threads because they didn't seem of any particular importance to me >>> at the time. >> >> The extra copies help avoid data loss, but if a disk is lost and there >> is no disk-wise redundancy, then the pool will be lost. > > I'm reading a lot of posts where folks don't seem to be understanding > each other, so let me try and re-phrase things. > > If you set copies=n, where n > 1, ZFS will _attempt_ to put the copies > on different block devices. If it can't, it will _attempt_ to place the > copies "far" away from each other on the same block device. > > The key word above is "attempt". Previous posters have shot this down > for "poor man's mirroring" because of the lack of guarantees. I suspect > these naysayers (and rightly so) are what Tim is recalling. > > -- > Carson > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
