We have a similar situation on our F740. We want to keep the volume size
small because:
a) Restores can take forever as the data size gets bigger.
b) 10-14 disks is a good compromise on reliability. Having 2 out of 14
disks go bad at one time is much rarer than 2 out of 51 disks.
c) If you upgrade disks/shelves in the future, you will likely do it a
volume at a time. We did this with a volume with 180GB and the volcopy took
6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that
should be 2-2.5x longer.
John
-----Original Message-----
From: Moshe Linzer [mailto:Moshel.Linzer@nsc.com]
Sent: Monday, September 18, 2000 4:31 PM
To: toasters(a)mathworks.com
Subject: Optimal volume size
We are moving from a 630 with a single 350GB volume (51x9GB SCSI) to a
new 760 with 14 36GB disks. Our Netapp support recommends creating a
14-disk raid group, with a single raid group per volume (giving us a
maximum volume size of around 400GB). I understand why 14 disks is a
good number for a raid group (balance chances of disk failure vs
efficient use of disks), but what is the reasoning behind keeping volume
size down to around 400GB? Is it just dependant on restore time from
tape? In which case, as faster tapes become available (LTO?), this
number should increase. Does it also lessen chances of file system
corruption on the volume, or is it just a warm fuzzy feeling that all
your eggs (so to speak) are not sitting in one 1.2 terabyte volume?
If my max volume size will remain the single raid group, I would like to
divide my data into 2 smaller volumes from the start, so I don't start
off with a maxed-out volume. This means using a time-consuming ndmpcopy
or rsync process to move the data, instead of the faster volcopy or
snapmirror.
Thanks for your insights.
Moshe