Here’s how I’ve dealt with personal-use/home-use disk management and ZFS in the 
past, which in terms of a timeline would date back to disk-size when a 250GB 
IDE disk was considered “decent”.

I would always buy my disks in sets of “three”.

I used to have two pools for years:

Pool A - a very important pool – being 3-way mirror.  Not the fastest, but that 
wasn’t my goal with this pool.

Pool B - a not so important pool for everything else – being clusters of three 
disks in RAIDz1. This pool tended to grow ;))
        Pool B eventually grew to be 15 disks (5 x 3 sets of raidz1) which 
ranged over the years from disk sets of 250GB, 500GB, 1TB and 2TB in size.
        I rarely used onboard connectors so I used aCard 6885M for IDE and 
Silicon Image 3132 for SATA.

All this was stuffed inside an old Apple ANS500 case (the PCI backplane 
eventually failed so I sadly guttered it and retrofitted whatever mobo was 
spare over the years)

Every year, I would “retire” disks that reached 4 years of age (4YoA) as they 
were running 24x7 at home.  I also felt it was time to reduce the number of 
spindles each time I upgraded, as I knew I was carrying a fair bit of risk 
having so many spindles!
Being able to add another raidz1 set to Pool B though is a great feature! run 
out of space? no big deal, just add more if you have spare ports…  (I dealt 
with a lot of PAL-DV video footage)

Today, I’m down to just the one pool of  5 x 4TB Seagate disks hanging off a 
RocketRaid 2744 which can drive 16 disks should I ever need more space quickly.

Over the years, I've lost a few disks here and there and so I would just bring 
forward my yearly replace > 4YoA program and retire the whole set of 3 disks. 
(I would use the remaining 2 disks in other projects)

All this is backed up onto old Xraids (7 disk raidz1 clusters) that are also 
running ZFS. I perform a scrub first, then push the snapshot to them.
These things are so damn loud that I only backup every fortnight and then 
they're all off again! 
About every 90 days I update another ZFS striped backup of my data and keep 
that in a briefcase at my parents house.

The above might sound a bit extreme for most, but the beauty of ZFS is that it 
gives you flexibility and scaleability to suit your own needs.

Whatever “design” is chosen for data management, make sure you have discipline 
to maintain it.
I find human neglect is just as often the root-cause of people’s misery when 
things don’t go to plan. 


> On 4 Nov 2014, at 6:40 am, Bjoern Kahl <> wrote:
> Hash: SHA1
> Hi Robert!
> Jason, as usual, said all the important stuff, so little to add, but ...
> Am 03.11.14 um 18:34 schrieb Robert Rehnmark:
>> The problem would not be the mirror.. I use consumer standard 
>> drives and they fail quite often. With two-way mirrors I would
>> risk a lot more trouble if the other drive dies too while
>> resilvering. (Transferring as fast as possible from one disk to
>> another with no other bottlenecks or ”breaks” and therefore
>> stressing the disk to a maximum.) Of course this might not be a
>> great risk in real life but I read that of all the disks that fail,
>> a quite big part do so while stressing them like this.
> This effect of failing the one remaining "redundant" disk, while the
> other is resilvering, is indeed a problem and I have seen this twice.
> But the same thing can happen in any configuration, not only with
> mirrors, but also in RaidZ.  Of course, the more dead disks a
> configuration can tolerate, the higher the chance to survive such a
> double-failure.
> Another thing I always recommend, no matter if setting up a mirror or
> a RaidZ:
> Buy disk from different manufacturers (not just different brands,
> really from different makers), and have them ship in two batches.
> The idea here is, that the two, three, ... disks making up one mirror
> or one RaidZ set do not have the exact same physical structure and do
> not have experienced the exact same shocks when falling of the truck at
> your gentle parcel delivery service.
> In the past 5+ years where I followed this rule, I have not seen a
> single double-failure (but three disk failure in total).
> Another thing:
> Do regular scrubs, and monitor your SMART values.  Although some disks
> seem to lie about their SMART health reports, it sometimes gives an
> early warning that a disk is getting dementia.
> (And some disks don't like to be monitored: I had two Seagate disks
> that reproducibly dropped of the bus when a host write request and
> SMART status inquiry arrived almost simultaneously.)
> Best regards
>   Björn
>> Anyways, if the speed of one raidz2 is enough for me I will 
>> probably stick with it since it feels a little more safe than 
>> two-way mirrors. It’s mounted in the computer cabinet so there 
>> isn’t all that much room for growing it except by migrating to 
>> larger drives. In any case, I’m investing in more and better 
>> hardware and if the speeds are to slow with the raidz2 I can go
>> for 3 two-way mirrors in the pool. Of course the full backup will
>> save me quite a bit of worry and that’s why I have now spent cash
>> on something that will hopefully work out well for me in that 
>> department.
>> Another thing. I’m feeling good about moving away from the
>> built-in sata controllers, and getting a controller card that I
>> hope will be a bit more dependable. Is it advisable to distribute
>> the disks for a certain vdev across more than one controller?
>> case the controller introduces errors? Or is that not recommended
>> for some reason?
>> Thank you very much for taking the time.
>> /Robert
>> 3 nov 2014 kl. 18:00 skrev BelecMartin 
>> <>:
>>> Not sure what you have read about mirrors, I have yet to see any 
>>> such issue across 15 such setups.
>>> Now Raidz2 also has its caveats, and for the average individual
>>> I really do recommend mirrors for actual redundancy. If you
>>> build Raidz2 then you need to do that as a mirror of another
>>> raidz2 or have a very good backup strategy and that almost always
>>> goes to mirrors. ;)
>>> I really don't see many people running into the memory issues 
>>> unless you turn dedup on, ouch! I can only speak from experience 
>>> but I have a good size client base all on ZFS running daily for 
>>> years. All issues can be tracked back to hardware failure and 
>>> that is to be expected. Also almost always easy to recover from 
>>> with ZFS.
>>> However everyone makes their own decisions on data at hand and 
>>> you may be ahead of the curve.
>>> Jason Belec Sent from my "It's an iPod, a Phone, and an Internet 
>>> Device..."
>>>> On Nov 3, 2014, at 11:39 AM, Robert Rehnmark 
>>>> <> wrote:
>>>> The tears are something I really want to avoid. Therefore I 
>>>> have already taken the financial hit and ordered drives and an 
>>>> external enclosure for backup purposes. I will not do
>>>> anything, not even resilvering, until tomorrow when I have been
>>>> able to make a full backup. (As of now, only the most critical
>>>> data is backed up.) I would like to avoid two-way mirrors in
>>>> the future since I read that resilvering often triggers failure
>>>> of the remaining drive if it’s in bad shape.
>>>> Yes, the pool is now two mirrors that are striped. As you say, 
>>>> it’s easy to grow and it’s fast but I’d like the extra 
>>>> redundancy that a raidz2 gives. I will see how it works out in 
>>>> terms of performance but the CPU and Memory should not be the 
>>>> problem. I’ve got a hexa core xeon @ 4,1 GHz and 24 GB RAM.
>>>>> This procedure to do what your asking has been around almost 
>>>>> since the beginning of ZFS, a little Googling can find the 
>>>>> steps. I suggest anything with the name Oracle at the top of 
>>>>> the page.
>>>> What procedure exactly are you referring to here?
>>>> Thank you for offering your tips and help. I’ll let you know 
>>>> how it goes. :)
>>>> /Robert
>>>>> 3 nov 2014 kl. 17:21 skrev Jason Belec 
>>>>> <>:
>>>>> Well a few things, if you don't have a backup already don't 
>>>>> go any further. Your just asking for tears  of anguish.
>>>>> This procedure to do what your asking has been around almost 
>>>>> since the beginning of ZFS, a little Googling can find the 
>>>>> steps. I suggest anything with the name Oracle at the top of 
>>>>> the page.
>>>>> You say 2 mirrors, do you mean they are stripped together? 
>>>>> How did your original creation command look? To receive aid, 
>>>>> you need to be detailed in asking as you could get advice 
>>>>> based on assumption that will have you back to the tears 
>>>>> thing....
>>>>> Are you looking for speed, security, redundancy? Because 2 
>>>>> drives mirrored and striped across 2 more drives mirrored is 
>>>>> pretty safe and can be grown by another 2 drives and 
>>>>> repeated. In fact I usually encourage this for most people 
>>>>> rather than RaidZ2 (something you cannot alter after 
>>>>> creation).
>>>>> -- Jason Belec Sent from my iPad
>>>>>> On Nov 3, 2014, at 7:25 AM, Robert Rehnmark 
>>>>>> <> wrote:
>>>>>> So I have decided to get an LSI SAS/SATA 8 port raid card 
>>>>>> for my hackintosh and change my pool from… 2 mirrors of 
>>>>>> 2x3TB Seagate Barracuda (4 drives)  —TO—> 1 RaidZ2 of
>>>>>> 6x3TB Seagate Barracuda My intention is to set up a
>>>>>> complete backup of the whole pool also but since that is
>>>>>> not done yet I can’t juggle the data that way.
>>>>>> Are there ANY options other than creating the raidz2 in a 
>>>>>> new pool, transferring all the data and then scrapping the 
>>>>>> old pool? Can I clone the pool with settings, filesystems, 
>>>>>> mountpoints and all onto a new pool? Can I mirror the old 
>>>>>> pool with the raidz and then scrap the old part of the 
>>>>>> mirror? This sounds dangerous though, making a vdev 
>>>>>> containing other vdevs.. (if even possible)
>>>>>> Thanks in advance for any advice. Robert
> - -- 
> |     Bjoern Kahl   +++   Siegburg   +++    Germany     |
> | "googlelogin@-my-domain-"   +++ 
> <>  |
> | Languages: German, English, Ancient Latin (a bit :-)) |
> Version: GnuPG v1
> RnARwjENWT+d93d5waM0qjLldVuovzednaj/63bGCBVp+SzFU+o9Or7l+q4f+xO7
> MtmYmY1ouUOJmGYnjpsCpnFbjjJaIdnxtSV02zPEzDP/fabBSrDVLV2H357Xri/w
> 2VrTpwBJ2r0=
> =vnaG
> -- 
> --- 
> 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 
> <>.
> For more options, visit 
> <>.


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 
For more options, visit

Reply via email to