We have developed an automation Ansible script which logs into the ONTAP System and fetch the details of the igroups whose initiators are not-logged in. This script logs into the ONTAP System multiple times, and in context to that please let us know if this can cause an issue on the Storage at any given time. Please highlight if this repeated login by the script on the ONTAP system can put the Storage in a non-ideal situation.   --> We also want to know the impact on ontap node i.e, CPU utilization on Ontap node to use the script to try login attempts to the storage after each 30 or 40 secs to fetch the requested information.  Please advice  --> What is the amount of CPU utilization may cause if the scripts attempts login for every 30s to Storage    Looking forward to your response.   Thank you! ... View more

I currently have three network interfaces (LIFs) that are not on their home ports, and I would like to revert them back to their designated home ports. Do we need to move any volumes as part of the LIF revert process, or can the LIFs be reverted independently? I spoke with Park Place support, and they advised that there is no need to move the volumes when reverting the LIFs to their home ports. Please let me know if you have any feedback or concerns. Thank you. ... View more

we migrated Netapp from A800 to A1K (9.16.1P12). Now during our epic/iris database backup, we are experiencing the reading performance on application. we are also seeing the high latency on disks from Netapp.   does anyone experiencing the same with a fix? thank you, ... View more

Good day all, we are working on Harvest (we've installed NAbox v4.2.0 via OVA) and I find it extremely useful for monitoring and trobleshooting. In these days it helped us finding the cause of a high latency peak on all (nfs exported) volumes of a Node. It appears clearly the root cause to be a high, sustained, almost fully random and 100% write workload that saturates the capacity of the SATA disks of the aggregate. I would like to have an help about this screeshot from the dashboard in the subject:   the time range is when the issue occurred. The red bar is pretty explicit 😀 I would like to focus on the meaning of the numeric metric: does "Max IOPs" means "the max number of IOPs per single disk"? Or? Thank you in advance. ... View more

Case description: FAS2520 / Data ONTAP 7-Mode: aggr0 double degraded, replacement drives detected as SAS 15000 and not accepted as matching spares, maintenance disk stuck in testing. Current problem aggr0 is currently double degraded. The RAID group shows two FAILED data members. We have available spare disks, but the system is not using them for rebuild. A maintenance disk (0a.00.3) remains in testing status. Observed behavior From aggr status -r: Aggregate aggr0 (online, raid_dp, degraded) (block checksums) RAID group /aggr0/plex0/rg0 (double degraded, block checksums) Two data positions in the RAID group show as FAILED From aggr status -s: Current spare disks are: 0a.00.1 → SAS 15000 0a.00.8 → SAS 15000 (at one point shown as not zeroed) From aggr status -r: Existing RAID group members are shown as FSAS 7200 Maintenance disks section shows: 0a.00.3 → testing, FSAS 7200 From disk show -v: 0a.00.3 shows OWNER = FAILED Drive identification inconsistency From storage show disk -T -x: 0a.00.1 and 0a.00.8 are identified as: Model = X477_SMBPE04TA07 Rev = NA00 Type = SAS Most other data disks in the shelf are identified as: Model = X477_SMEGX04TA07 Rev = NA03 Type = FSAS We also replaced the disk in slot 0a.00.8 with another brand-new replacement drive, but the newly inserted disk was still detected as SAS / RPM 15000. What we already checked raid.disktype.enable = off raid.rpm.ata.enable = off Broken disks (empty) from aggr status -f Current spare disks are owned by the controller and use block checksum Another new replacement drive inserted into 0a.00.8 still shows as SAS 15000 Our concern It appears that the available replacement drives are not being accepted as valid matching spares for aggr0, possibly because the RAID group members are shown as FSAS 7200 while the replacement drives are detected as SAS 15000. We need help with Please confirm whether the replacement drives/FRUs are correct for this platform and RAID group. Please confirm whether there is a disk qualification / drive firmware / recognition issue causing the system to identify replacement drives as SAS instead of FSAS. Please advise the supported recovery procedure for aggr0 in the current double degraded state. Please advise how to handle maintenance disk 0a.00.3, which remains in testing and also appears as OWNER = FAILED. Commands / outputs available We can provide the outputs of: aggr status -r aggr status -s aggr status -f storage show disk -T -x storage show disk -x sysconfig -d disk show -v options raid.disktype.enable options raid.rpm.ata.enable Please advise next steps. Best regards ... View more