While the subject is ‘i2p’, this isn’t an email telling you about the mapping that causes some high utilization, rather it is about the aftermath of the i2p mapping process.

I recently performed an upgrade of some of our nearstore systems (used for email compliance, among other things), and was expecting a pretty serious utilization curve while the i2p mapping was performed as part of the upgrade (we upgraded from 7.0.6, not 7.1.X).  This came and passed with high utilization of CPU and DISK, but no real issues.  However, the i2p mapping apparently keeps the inode-2-path map for every file\inode in the metadata – we have volumes with snaplocked data in the terabytes, the most heavily utilized of which is about 110million files (the 2^nd highest utilized is about 82million).  As this data has been marked as ‘archive’ in the Enterprise Vault system, it isn’t being written to anymore, so I’m not terribly concerned with the snapmirror update taking a while – however, it is throttled down pretty low as our WAN is not yet up to snuff (coming later this year).  Apparently, because i2p touches each inode, we have about 110million*4KB to transfer (~420GB) for the ‘update’ to our 4.2TB volume.  Likewise, the 3.2TB volume with 82million files had about 313GB to transfer.

If you have volumes with a significant amount of files, be aware that the snapmirror update after the i2p process completes post-7.2.2 upgrade (or 7.1.1 even, I suppose) will be fairly significant in size.

Hope this helps some of you out there so that you are not caught unaware.

‘evening

Glenn