Netapp Filer – can I resize an aggregrate

Here's a link to the ifconfig man page for ontap: http://ecserv1.uwaterloo.ca/netapp/man/man1/na_ifconfig.1.html

Here's one for the cifs commands: http://ecserv1.uwaterloo.ca/netapp/man/man1/na_cifs.1.html

changing your IP would be something like this (you would want to do this when logged in from the console in case it's not obvious):

# Get the name of the interface your current IP is assigned to, as well as 
# netmask, etc
ifconfig -a

# down the interface (i'm not actually sure if this is needed)
ifconfig INTERFACE down

# bring the interface back up with the new network info (substituting the
# correct values for INTERFACE, NETMASK, and ADDRESS)
ifconfig INTERFACE ADDRESS netmask NETMASK ip

You might also have to edit some files in the filer's etc/ dir to make the change persist across a reboot, as I said it's been a long time. cd to the filer's etc and grep for the current IP to get an idea.

as for renaming the share... Looks like you can't do a straight rename, you're in for deleting the old one and recreating it with the new name. How about something like this:

# show the info about the current shares:
cifs shares

# change the share name
cifs shares -delete OLDSHARE

# add the new name with the same settings as the old
cifs shares -add NEWNAME [options]

See the na_cifs_shares man page for more infor on the options when you recreate the share (http://ecserv1.uwaterloo.ca/netapp/man/man1/na_cifs_shares.1.html)

Hope that helps somewhat...

The most interesting part of the output above is the systat gathered during the dump. We see a pegged CPU, but that can be misleading because the systat -x CPU output only shows the highest pegged CPU, not a per-core average. But, we see something else interesting. We're almost constantly doing CPs, and they are H CPs (high watermark.) This indicates that the data in NVRAM to be committed to disk has exceeded the high watermark. So we're going to block client requests to try and flush the NVRAM data to disk. But, to complicate things we're only doing about 20-25MB/s in and our CPs are happening every second, and sometimes taking 3 seconds to complete. That math doesn't check out. I'm not sure what the per-HA-partner NVRAM size is on a 2240, but I know it is at least 256MB per head, and probably larger. At 25MB/s that's 8-10 seconds to hit high watermark, and we'd commit before that anyway, and that's not what we're seeing here.

All in all the output above hints at the filer doing something else behind the scenes. I would suggest digging into systat -m to see what domain is most active. If it is Kahuna and one core is pinned at 100% then we could be hitting a WAFL bottleneck. I'd also evaluate any other background processing that may be occurring (sis jobs, snap* jobs, etc.)

If you can't track it down yourself then reproduce the issue while gathering a perfstat and hit up NetApp Support.