What will happen if I add a disk to a volume (NetApp C720)? I learned the hard way that adding the drive to the shelf interrupted all NFS ops for 15 seconds, the docs said it would take that long to add it as a hot spare, but didn't mention that the filer would completely freeze while it did it. If I add a disk to a volume, what will it do to performance, and for how long? I don't mean long-range gains from having the data spread over more spindles, I mean what immediate impact will it have on current NFS clients. Will it just be a temporary increase in CPU as it spreads the data or will it freeze for some period of time, and if so for how long? Current sustained load on the filer is several hundred NFS ops/sec, and any pauses cause significant problems on the client systems, so I want to have a better understanding of what will happen when I give the vol add command before I actually do it.
Thanks, Frank -- Frank Smith fsmith@hoovers.com Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
If I add a disk to a volume, what will it do to performance, and for how long? I don't mean long-range gains from having the data spread over more spindles, I mean what immediate impact will it have on current NFS clients. Will it just be a temporary increase in CPU as it spreads the data or will it freeze for some period of time, and if so for how long?
Frank,
Adding a disk into a volume will cause increased CPU and I/O load for < 10 minutes while data is copied over. It won't freeze the system or do anything disasterous like that.
If you're only running at a couple of hundred nfs ops/sec, you don't really have anything to worry about unless you have client applications which are extremely sensitive to filesystem performance (in which case you probably shouldn't be using nfs anyway). In fact, it's quite likely that your clients aren't going to notice anything while the disk is being added to your volume.
Nick
Adding a disk into a volume will cause increased CPU and I/O load for < 10 minutes while data is copied over.
"Copied over"? When you add a disk to a volume, we zero it (so that adding it to a RAID group doesn't change the parity value for the stripes it joins); we don't copy data (in the sense of data written to the file system on behalf of clients) to it.
That will (if the disk isn't one that supports the SCSI "WRITE SAME" command, or that supports it but not reliably) consume some CPU time and I/O bandwidth writing to the disk. If the disk does support WRITE SAME, it requires less CPU and I/O bandwidth (a chunk of zeroes should get transmitted to the disk once, and then the disk should write that chunk of zeros to a large block of sectors - we don't zero the entire disk in one command, in part so that, as I remember, we can give a progress indication, and for other reasons I no longer remember).
If I add a disk to a volume, what will it do to performance, and for how long? I don't mean long-range gains from having the data spread over more spindles, I mean what immediate impact will it have on current NFS clients. Will it just be a temporary increase in CPU as it spreads the data or will it freeze for some period of time, and if so for how long?
Adding a disk into a volume will cause increased CPU and I/O load for < 10 minutes while data is copied over. It won't freeze the system or do anything disasterous like that.
I think this is right, of course there is the possibility that this only works with actual failed disks, but...
if you are really paranoid about the possible impact adding a new disk to an existing volume will have on your filer you can play with the raid.reconstruct_speed option. crank it down and you should see very minimal impact to the system, but it will take aproximately forever to finish. crank it all the way up and clients may start having issues accessing the filer. i've found that staying around 6 seems to speed things up a little ( maybe it's the placebo effect ), and not impact performance terribly... default should be 4 which on most of my filers is about right.
-s