Kent Watsen wrote:
>
>>> But to understand how to best utilize an array with a fixed number of
>>> drives, I add the following constraints:
>>> - N+P should follow ZFS best-practice rule of N={2,4,8} and P={1,2}
>>> - all sets in an array should be configured similarly
>>> - the MTTDL for S sets is equal to (MTTDL for one set)/S
>>
>> Yes, these are reasonable and will reduce the problem space, somewhat.
> Actually, I wish I could get more insight into why N can only be 2, 4,or
> 8. In contemplating a 16-bay array, I many times think that 3 (3+2) + 1
> spare would be perfect, but I have no understanding what N=3 implicates...
There was a discussion a while back which centered around this topic.
I don't recall the details, and I think it needs to be revisited, but
there was concensus that for the time being, best performace was thus
achieved. I'd like to revisit this, since I think best performance is
more difficult to predict, due to the dynamic nature of ZFS making it
particularly sensitive to the workload.
>>> While its true that RAIDZ2 is /much /safer that RAIDZ, it seems that
>>> /any /RAIDZ configuration will outlive me and so I conclude that
>>> RAIDZ2 is unnecessary in a practical sense... This conclusion
>>> surprises me given the amount of attention people give to
>>> double-parity solutions - what am I overlooking?
>>
>> You are overlooking statistics :-). As I discuss in
>> http://blogs.sun.com/relling/entry/using_mtbf_and_time_dependent
>> the MTBF (F == death) of children aged 5-14 in the US is 4,807 years, but
>> clearly no child will live anywhere close to 4,807 years.
> Thanks - I hadn't seen that blog entry yet...
>
>
>> #define MTTR_HOURS_NO_SPARE 16
>>
>> I think this is optimistic :-)
> Not really for me as the array is in my basement - so I assume that I'll
> swap in a drive when I get home from work ;)
It is an average value, so you have some leeway there. I work from home,
so in theory I should have fast response time :-)
>> There are many more facets of looking at these sorts of analysis,
>> which is
>> why I wrote RAIDoptimizer.
> Is RAIDoptimizer the name of a spreadsheet you developed - is it
> publically available?
It is a Java application. I plan to open-source it, but that may take a
while to get through the process. I'll check to see if there is a way to
make it available as a webstart client (which is how I deploy it).
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
