Reading LUN Stats -o

netapp1> lun stats -o
    /vol/UCvol/UClun  (98 days, 0 hours, 46 minutes, 51 seconds)

Read(kbytes)	Write(kbytes)	ReadOps	WriteOps	OtherOps	QFulls	PartnerOps	PartnerKBytes
15940415	640772	30487379	8734	9767	0	30442488	15496708

A few things about this are not immediately intuitive.  First, statistics labeled "Partner" are indirect IO, passed through the cluster interconnect.  This means both heads have to process the information, which is adds up to considerable overhead in terms of work and latency.  

Second, the statistics not labeled  "Partner" are totals: they include both the direct and indirect IOPS.  At first glance you'd see that ReadOps is a very close number (.1% off) to PartnerOps, which would indicate that the traffic is being load balanced across indirect paths.  

But that would be counting the same Ops twice.  If you add up ReadOps, WriteOps, and OtherOps, that's the total number of direct and indirect Ops.  If you then subtract PartnerOps, that resulting number (63392 Ops) is the number of direct Ops.  That's .2% direct IOPS, which indicates a serious pathing configuration issue.

De-Mystifying Obscure NetApp Warnings

SAN volume with a non-UNIX security style:  "The recommendation has to do with avoid auditing that is usually performed by ONTAP on files (NAS) which could add unneeded IOPS to the system." 

Security style means the method the filer uses to determine whether a user has access to a file.

unix

The user’s UID and GID, and the UNIX-style permission bits of the file or directory determine user access. The filer uses the same method for determining access for both NFS and CIFS requests. If you change the security style of a qtree or a volume from ntfs to unix, the filer disregards the Windows NT permissions that were established when the qtree or volume used the ntfs security style.

ntfs

For CIFS requests, Windows NT permissions determine user access. For NFS requests, the filer generates and stores a set of UNIX-style permission bits that are at least as restrictive as the Windows NT permissions. The filer grants NFS access only if the UNIX-style permission bits allow the user access. If you change the security style of a qtree or a volume from unix to ntfs, files created before the change do not have Windows NT permissions. For these files, the filer uses only the UNIX-style permission bits to determine access.

mixed

Some files in the qtree or volume have the unix security style, and some have the ntfs security style. A file’s security style depends on whether the permission was last set from CIFS or NFS. For example, if a file currently uses the unix security style and a CIFS user sends a setACL request to the file, the file’s security style is changed to ntfs. If a file currently uses the ntfs style and an NFS user sends a setpermission request to the file, the file’s security style is changed to unix.

Volume option create_ucode set to off: "A non-unicode directory will be converted to Unicode the first time it is touched by any protocol that requires Unicode directories. It is recommended that create_ucode is set on every volume (NAS and SAN) as converting large directories can delay a takeover operation for longer than the takeover time limit"

"Setting this option to on forces UNICODE format directories to be created by default, both from NFS and CIFS.  By default, it is set to off, in which case, all directories are created in pre-4.0 format, and this first CIFS access will convert it to UNICODE format."

Volume option fs_size_fixed is set to on for a non-mirrored volume - the source side locks the volume size to prevent the source becoming larger than the destination.  If this is on for non replicated volumes, this can result in a full volume by preventing auto grow.    Related: “You can increase the size of the source volume for a FlexVol volume. After you increase the size of a source volume and perform a SnapMirror transfer, the size of the destination volume is automatically increased to the same size as that of the source volume, provided the destination aggregate has sufficient space to contain the resized volume.”  https://library.netapp.com/ecmdocs/ECMP1196991/html/GUID-90D4160B-691B-405E-A26A-D592539555B0.html

Exposure to bug 488909 - Xcopy memory corruption: XCOPY is a vmware VAAI feature that lets the storage system do the copying rather than a host reading and then writing a bunch of data.  We have a bug associated with this, so they need to upgrade ontap.  http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=488909

Reader Question 1: CIFS Changes

Question from a reader!

"Quick question for you. If I move a system to a different subnet and change the IP and rename it, will CIFS shares be affected in any way? Isn’t there an SID that is generated when CIFS is setup. Would that need to change?"

The Active Directory GUID  doesn’t change with the IP address, so if you're only changing the IP you'll just need to update DNS.

But when you change the system name you’ll want to remove the system from the domain, change the IP and/or name, then rejoin the domain under the new name.  

Anyone using the cifs shares will of course be affected by this, since shares are in the format \\\share or \\\share.  Everyone would have to update their shares, their mapped drives, their scripts, saved paths, etc.  

CDOT Raid Groups

A cool bit of trivia about expanding RAID Group sizes.  

For the command storage aggregate modify

For the command storage aggregate add-disks(both quotes from 8.2 command manual)

Which means if you need to balance an unusual number of disks today but will add more disks at some future date, if you want to have small RG’s now and expand them in the future you have to be careful.  For example, if you have 45 disks and want a RG size today of 15 but 20 later, you’d do this:

Storage aggr create –aggregate aggr1 -diskcount 15 –disktype SAS –maxraidsize –s 20

Storage aggr add-disks –aggregate aggr1  -diskcount 15 -disktype SAS –raidgroup –g new

Storage aggr add-disks –aggregate aggr1 -diskcount 15 -disktype SAS –raidgroup –g new

But then we found this:

(Clustered Data ONTAP 82 Physical Storage.pdf)

While this excerpt doesn’t explicitly state you can, I tested in the lab and confirmed: you can manually expand RG sizes of all the RG’s in the aggregate by modifying the max RG size then manually adding disks to each RAID Group.

Storage aggregate add-disks –aggregate aggr1 -diskcount 5 -disktype SAS –raidgroup rg0

Dedupe

Couple quick points on dedupe:

1. sis start /vol/volname is a "from this point forward" command.  It does automatically go back to any existing data and dedupe it.
2. Volume snapmirror is dedupe aware
3. Qtree snapmirror isn't dedupe aware.  You can enable dedupe independently on the source and destination.
4. It's good to run sis start -s on older volumes.  Cleans up stale fingerprints, improves efficiency, and does dedupe the existing data in the volume.  If you run this on the source vol that is snapmirrored, it also affects the dest vol.
5. If you're enabling dedupe on an existing volume, run sis start -s during off hours to tackle existing data.

https://communities.netapp.com/community/netapp-blogs/drdedupe/blog/2010/06/17/snapmirror-and-deduplication--dedupe-here-there-or-everywhere