Hi Jim,
Jim Davis jdavis@CS.Arizona.EDU writes:
Potential plan: buy a shelf of 9GB disks, put it on toaster A, move a shelf of 4GB disks to toaster B, keeping all of the toaster A data on toaster A. Toaster B ends up with an empty file system on its 4GB disk shelf.
Now the mechanics of the move are a little unclear to me. Presumably we hook up the 9GB shelf to toaster A and 'raid fail' each 4GB disk in the shelf we want to move? But there will be 5 9GB data disks, since we have to burn one as a hot spare and one becomes the new parity disk. Will there be a problem with having 7 disks to move data from, but only 5 disks to move data to? There would be enough GBs on the 5 9GB disks, but...
I'd propose this plan of action:
Buy enough 9GB disks to support all data resident on 4GB disks.
Install Data ONTAP 5.0.
Attach 9GB disks and create second volume.
Run NDMPcopy to transfer vol0 -> vol1 (special care required if you use incrementals).
Make vol1 the root volume
Offline & destroy vol0 after vol1 deemed okay!
Break up 4GB disks between filer A & B.
Create second volume on Filer A using leftover 4GB disks.
Alternative is:
dump data to tape (quota trees would be useful)
Break up 4GB disks between filer A & B
Add 2 volumes to Filer A using 4GB & 9GB disks
restore from tape to any volume (again quota trees would be useful)
You have to get *all* the data off the 4GB disks before you can free any of them up (as Dan already pointed out). We don't have an EVACUATE command.
Note for the future:
We aim to have a volume copy command in a future release that will allow a larger volume (measured by disk capacity) to be transferred to a smaller volume (measured by disk capacity) as long as the resident data will fit.
You will need to use NDMPcopy to transfer the volume if you do it with one filer and multiple volumes since BareMetal Migrate is only available in the 4.3. software release. With two (single volume) filers in play BareMetal Migrate is just the ticket.
Cheers, Grant
Make vol1 the root volume Offline & destroy vol0 after vol1 deemed okay!
A warning here. There's currently a bug in Ontap5.0R1 related to destroying a large volume. I had two volumes, vol0 (two disk root volume) and vol1 (22-disk data volume). I did a vol destroy on vol1.
The toaster then worked fine until the next reboot. Then it failed to reboot. I had to put in the floppy, and hit the "normal boot" option.
A "download" command made it so it booted successfully (until the next time I did a "vol destroy" on most of my disks).
So the warning is: until the bug is fixed, if you do a vol destroy on a large volume, run a "download" command after the "vol destroy" is complete, but before the next reboot.
---- Here's my theory as to the cause (translation: guess):
The netapp mirrors the OS on the header of all the disks.
At least half of the disks must have the same OS copy/version/checksum/magic-number in order for the netapp to boot correctly (guess #1)
The "vol destroy" uses a hardware-quick-erase feature which blows away the whole disk, not just the data portion. This blows away the OS portion of the disk.
Viola! After a vol destroy on 22 of my 24 disks, I now have a valid OS on less than half the disks. Non-floppy boots fail until I get it up with a floppy, and run download (but no data is lost).
----
This bug has been reported to Netapp, and they're working on it.
By the way, I've been favorably impressed with the reliability of Ontap-5.0 in my current benchmarking/testing project. Based on my observations (100% unix, no NT observations), I wouldn't hesitate to put it on my production servers at this time. The "vol destroy" on that many disks is a pretty abnormal operation for a production server---you just have to remember to run "download" until they patch it.
----
Darrell Root rootd@nas.nasa.gov