Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.To learn more, read the FAQ and watch the video.Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.
You must be very careful here however. NDMP jobs of any type are notoriously sensitive to inode counts. This means that backups and ndmpcopy will take longer on the same size volume once you increase the inode count. Also snapvault and qtree snapmirror jobs are affected by increasing inodes as there is an ndmp component.
Once you increase the count, there is really no way to ever go back. So if you find you have performance issues, there is only one fix - migrate the data to other volumes using host based copies, destroy the volume.
Let me state out in the open, I have done the 20/20 increase many times and have not really seen major problems outside the backup times increasing. I have also had my team be forced to go beyond the 20/20 increase and seen a controller taken down by simply running an "ls" which is the Unix equivalent of "dir". The guidelines are in place for a very good reason and should be followed.
Lastly there used to be a bug that volumes over 1TB in size did not have the inode count calculated properly. It was not scheduled to be fixed, if this is a large volume, you may have to do the required calculations and set the inodes to the proper count for your volume size. The bug ID is 199233