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@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