This simply means that you have too many files in your directory. The message about "hard links" is a bit misleading. Every directory can only contain 100.000 files/subdirs max. This has to do with OnTap having to read the entire directoryfile in when accessing the directory, and with 100.000 files in one directory you're aproaching a few megs per directory, which is a lot if you have to constantly read/write it (e.g. for atime updates) There's no (documented/supported) way you can override this limit. -Michael ... View more

Just create a new share one level up from the folder you want deleted, then connect to that share, delete your folder, and remove the share again (if you want) -Michael ... View more

For root mounts to work you have to add "root=<ip>" to your /etc/exports file for that volume. Otherwise all root mounts are treated as nobody-mounts and you won't get access. Also, the option "cifs.nfs_root_ignore_acl" might help you. If set to yes, "root" users from unix ignore windows ACLs (they are basically treated as windows admins) -Michael ... View more

I don't understand where the problem is. If you have a volume, simply put it in /etc/exports for your NFS access, and create a share on it via "cifs shares -add" (or via System Manager/FilerView). For ESX the volume needs to have UNIX style security and the ESX host must have rw AND root access to it. -Michael ... View more

Simple: you can't overstep it. It's a hard limit that has to do with 32 bit block access. 0xffffffff * 4096 bytes/block = 16TB. If you try to add more disks, the system will give you an error message. In your case I would create 2 aggregates with ~8.5tb each, however, I would stick with one spare disk. You don't really need one spare per shelf -Michael ... View more

simply remove the cluster_remote license and the message will disappear. The only impact it will have is that it will disable the "cf takeover -d" command, which is only meaningful in MetroCluster environments. If you have a simple (non-syncmirrored) cluster, you don't need the cluster_remote license. You can always add it back later if you decide to use MetroCluster -Michael ... View more

It can (and will) also happen if you put a disk that only supports 2gbit FC (for example a 10k RPM, or an older 15k RPM disk) into an ESH4 shelf on a 4gbit loop. ... View more

You should do this from a windows/unix host, wia rsh or ssh. That way you can put the output file somewhere on your PC (or even on the network). You can also timestamp / mail it. -Michael ... View more

This is not officially supported, BUT it can be done if you're careful. First, connect via the BMC and use "system console" to login to the filer. Then type "ifconfig vif0 down; vif delete vif0 e0a; ifconfig vif0 up" as ONE command. it will take the IF down, remove e0a and re-enable the VIF. If you typed everything correctly everything will work after that.. If you have a typo, however, then your VIFs will stay down and you're in trouble... Another (potentially safer) method is to edit your /etc/rc files on both nodes. Search for "vif create vif0 e0a e0b e0c e0d" or similar, and change it to "vif create vif0 e0a e0b" (i.e. remove the interfaces you don't want). Then do a takeover/giveback cycle for both filers to have them reboot. Takes longer but is potentially safer... -Michael ... View more

FC LUNs are always visible on BOTH cluster nodes at the same time. So even though your LUN physically resides on controller A, you can access it through controller B, which "forwards" the requests to controller A. If Controller A dies, controller B takes over and will become responsible for the LUNs. If your fabric still works when one of the brocades dies depends on the zoning. Since LUNs are always visible on both controllers at the same time, if zoning is correct it will definitely work. This is called  the "single image" mode (which is now the only supported fc mode). Check if your ESX hosts see two paths to your LUNs. If so, you're safe. But make sure that you install the ESX host utilities or use ALUA on your iGroup. -Michael ... View more

NDMPcopy un-deduplicates the data since it works on file level. QSM and SnapVault won't work either. The only things that keep data deduplicated are VSM and vol copy. Oh, and SM2T but I don't think that'll help you either -Michael ... View more

I admit don't know about what error happens if conversion fails when convert_ucode is set to on. The point I was trying to make is, that with convert_ucode=off, the file name has to be converted every time. If you set convert_ucode=on, the converted name will be stored (and you might get an error if the volume is read only) At least that's how I understood it. -Michael ... View more

If you set the timezone correctly on your NetApp (I use "Europe/Berlin" for example) it should get DST time right. Use the "timezone" command for that (or FilerView, System Manager, etc.) -Michael ... View more

I hope I can answer some of your questions. Note that these answers are not official but are based on my understanding of these options, and info I gathered from NetApp workshops and by talking to NetApp people. I might be wrong on some of them. If CIFS (using SMB 2.0) is UTF-16, then is ONTAP writing directory and file names using UTF-16? no, OnTap always uses UTF-8 as it occupies far less space (>90% of characters use only 1 byte). UTF-8 and UTF-16 are 100% compatible and can be converted into each other with no loss of information, only UTF-8 encoded text is smaller for most western languages that's why it is used. Also, SMB 2.0 uses UCS2 and not UTF-16. If NFS v4 is UTF-8, does ONTAP use UTF-8 for writing directory and file names from NFS v4? yes, if you set create_ucode and convert_ucode to on. Otherwise it will be converted When a file name is “converted” to UTF-X on CIFS access, it is suggested this is a "one time" conversion, and the name of file also converted on disk. Is this correct? That is what convert_ucode is for. If you have it set to off, the filename is converted everytime a CIFS client accesses it If CIFS is using UTF-16, why are the ONTAP volume language codes specified as “en.UTF-8”? If the file and directory names on disk are UTF-8, then does ONTAP always translate UTF-8 to UTF-16 when communicating with a CIFS client? the "en" is the "old-format" file name, the UTF-8 is used for NFS accesses. This has nothing to do with create_ucode and convert_ucode, which defines the way file names are stored in WAFL (if one of these 2 volume options is ON, OnTap saves 2 file names for each file, the "old" one and an UTF-8 encoded one which gets used on UTF-8 accesses). AFAIK the "old-format" file name is not removed but retained, but I'm not sure For environments that are predominantly (or exclusively) NFS, and include many NFS v2/v3, is it ill-advised to turn the convert_ucode option on? It would mean excessive conversion. It shouldn't matter since the ".UTF-8" on the volume language defines the NFS character set, and if there's an UTF8 file name (as created by create_ucode or convert_ucode), that one will be sent to the client. Otherwise it will be converted on-the-fly. In the statement (which was found on the web) – “Data ONTAP converts a directory format from pre-Data ONTAP 4.0 to Unicode”, what is the “pre-Data ONTAP 4.0 format”? The "old" file name (i.e. the non-unicode one) Hope that helps -Michael ... View more

Hi, you should open a case with NetApp for this. But I can tell you what they'll say: it's only a display bug, it's cosmetic, and everything is calculated correctly "under the hood".. We opened about 3 or 4 cases with this problem for different customer systems, and they were all closed with that argument. Good luck -Michael ... View more

I tried this once and failed (i.e. it was missing lots of the required libraries). -Michael ... View more

by default the filer will not take over on a multiple-link failure. To enable it, set the option "cf.takeover.on_network_interface_failure" to on. Note that this only applies to interfaces that have the "-nfo" (negotiated failover) flag set. i.e. you have to change your /etc/rc to include this flag in the ifconfig command line the other filer will take over when ALL these marked interfaces are down. to change it to take over whenever ANY of the flagged interfaces are down, set the option "cf.takeover.on_network_interface_failure.policy" to "any_nic" see the manual page for the "options" command for more info, as well as the active/active admin guide. -Michael ... View more

This is apparently a bug in system manager. It should be fixed in the next version (2.0). Meanwhile you can use the CLI interface ("cifs access" command) or the computer management MMC plugin (start->run, "compmgmt.msc", right-click your hostname and select "manage other server" or whatever it is called, enter the hostname of your filer and modify your shares there) -Michael ... View more

Note that OnTap 7.3.5 has been recalled, you shouldn't be using it. Use 7.3.5.1 or 7.3.5.1P1 if it's available -Michael ... View more

We've been wondering about the same thing recently. Disadvantages of large window sizes are the same on all systems, windows, linux, etc. NetApp is no different: Larger window means more data to retransmit on a lost packet for example since the full window needs to be resent. Also, it *might* make it easier to OOM the filer (out-of-memory) since every packet sent through the net has to reserve a full window, so I wouldn't make it too big, even on a perfectly reliable network. The default window sizes have changed in recent OnTap versions. We don't have any performance measurements yet, but we prefer to not touch them unless we have a specific issue which we're trying to debug... some official insight in these values would be nice -Michael ... View more