NETAPP TECHNICAL REPORT

Inode to Pathname (i2p) Feature of Data ONTAP

Uday Boppana, NetApp
June 2008 | TR-3679

A DETAILED DISCUSSION OF THE I2P FEATURE, IMPACT, AND USES

The Inode to Pathname (i2p) feature was introduced in NetApp Data ONTAP 7.1. This technical
report discusses the i2p feature in detail, its impact on the data stored on the storage system, and its
interactions with other Data ONTAP features. It also gives the formulas that can be used to estimate
the impact of i2p on the system and on other Data ONTAP features.
TABLE OF CONTENTS

1 INTRODUCTION ......................................................................................................................... 3
2 OPERATION ............................................................................................................................... 3
3 USES AND ADVANTAGES OF I2P ........................................................................................... 3
4 IMPACT OF I2P AFTER DATA ONTAP UPGRADE ................................................................. 4
5 DATA ONTAP USER INTERFACE ............................................................................................ 5
6 CONCLUSION ............................................................................................................................ 7

2 Inode To Pathname (i2p) feature of Data ONTAP

1 INTRODUCTION
An inode is an on-disk data structure that is used by file systems, including WAFL, to store metadata about
a file. There is one inode on the disk for every directory, file, soft link, and other internal metadata files
present in the file system. Inode to Pathname (i2p) is an efficient and protocol-independent per volume
WAFL feature that was introduced in Data ONTAP 7.1; it is enabled by default. It provides the ability to map
an inode number and a volume name to all storage system relative pathnames for that inode. This mapping
is used by a variety of external applications such as FPolicy servers and virus scanning servers. It is also
used internally in Data ONTAP to generate meaningful output messages and faster and more efficient
operation.

2 OPERATION
The i2p feature updates a small amount of data in all the file and directory inodes present in the volume and
creates a new metadata file for volumes with files that have hard links. This data allows every file inode to be
mapped to a storage system relative file system path for that particular file. For files with hard links, it gives
all the storage system relative paths pointing to that file. So, given the inode number and the volume name,
it gives the ability to find all path names, including hard-linked path names, in the volume for that inode.
Similar mapping can be obtained for inodes present in Snapshot copies, provided that i2p scan was fully
completed at the time when that Snapshot copy was created. This feature is enabled by default in Data
ONTAP 7.1 and later releases. The scan has minimal impact on the storage system performance, because it
was designed to be an efficient background operation.
Upon upgrading from a pre-7.1 release of Data ONTAP, one WAFL i2p scan is started in the background for
every volume present in the system. Each scan updates 8 bytes of data in every inode that is currently being
used in the volume. For volumes that have files with hard links, the scanner creates a metadata file and
adds 12 bytes of data for each hard link. The updated data in the inode and the metadata file hold the
necessary references to map an inode to all of its storage system paths. When the scan is complete, this
information is readily accessible from the inode. The i2p information is then updated every time a file system
operation that modifies this data is performed. The operations that generally trigger an update are creating,
deleting, and renaming a directory, file, or hard link.

3 USES AND ADVANTAGES OF I2P

Data ONTAP and WAFL provide one of the most space- and computation-efficient methods to map an inode
to all its paths, by using the i2p feature. This is possible because of the inherent structure of WAFL. The
inode-to-pathname mapping is used for a variety of reasons, both in Data ONTAP and by external
applications.

EXTERNAL APPLICATIONS
FPolicy services: FPolicy refers to the storage systems file policy feature, which provides a flexible
way to implement file policies through the use of a specialized off-storage system server. It is an
infrastructure that allows external servers to register certain file system events (for example, file open,
create, remove, rename, and directory create) and to receive callbacks when these events actually
occur on the storage system as a result of a client access. FPolicy events triggered through NFS need
the i2p information to report the complete file path to the FPolicy servers. The i2p information is used to
convert the inode number reported by the NFS client to a complete file path.
Virus scanning services for UNIX and NFS clients: External virus scanning servers need a
complete file path to check for virus signatures. The i2p feature supplies this file path by converting the
inode number provided by NFS clients to a file path.
CIFS ChangeNotify requests: In a multiprotocol environment, the i2p feature allows CIFS change
requests to be posted for files that are being accessed by NFS clients for various NFS file operations.
File auditing: Auditing file accesses and other file-related operations requires a complete file path.
Some file operations reference a file by its inode number, so the i2p information is required to translate
the inode number back to the file path and to record the information for audit purposes.

3 Inode To Pathname (i2p) feature of Data ONTAP

DATA ONTAP INTERNAL USE
User-friendly error reporting from within Data ONTAP: Some Data ONTAP error messages
present the complete file path for the file instead of an inode number.
Efficient Internal operations: Some Data ONTAP internal operations are faster and more efficient
if i2p information is available.
Efficient implementation: I2p provides efficient implementation for some Data ONTAP features.
o The dump command in Data ONTAP 7.3 completes faster if the i2p information is
available.

The i2p feature is turned on by default in Data ONTAP 7.1 and later and should remain turned on for
improved and efficient performance. All features in Data ONTAP 7.1 work without the i2p information,
but i2p provides a more efficient method. However, in later versions of Data ONTAP, some features
require the i2p information in order to function properly. Also, if i2p is not enabled, the external
applications listed that depend on i2p might not function properly.

4 IMPACT OF I2P AFTER DATA ONTAP UPGRADE

Upgrading Data ONTAP from a pre-7.1 version to 7.1 or a later version enables the i2p feature by default,
and a WAFL scan is started in the background to update the i2p information in the inodes.
The extra data that is updated in every inode by the i2p scan affects the data replication features of Data
ONTAP, including volume SnapMirror, qtree SnapMirror, and SnapVault. The extra data that is updated
and added on the source is sent to the destination. The amount of data transferred because of updating
every in-use inode in every online volume with the i2p data is a one-time occurrence following the source
storage system Data ONTAP upgrade.
The procedure outlined in the following sections can be used to roughly calculate the amount of data that will
be updated per volume and also the amount of data that will be transferred or archived for each volume.
Note: This is a rough estimate, because some amount of metadata also gets transferred.

ON-DISK UPDATES
Obtain the inode usage information for the volume by using the df i command. The iused column in the
output gives the total inodes that are used in that volume, and the ifree column gives the number of free
inodes. So the total inodes in the volume is the sum of used and free inodes.
All disk reads and writes in Data ONTAP and WAFL are made in blocks of size 4KB. Each 4KB block can
have 21 inodes in it. The exact size of the data that is updated on the disk depends on the distribution of
inode file blocks on the disk.
After the i2p scan completes, the minimum amount of inode update-related data that will be written to the
disk is equal to ceiling((Used inodes/21)) * 4 KB
The maximum amount of inode update related data that might be written is equal to
ceiling((Total inodes possible in the volume /21)) * 4 KB
Note: The ceiling function returns the smallest whole number greater than or equal to the number given as
the parameter. Therefore, ceiling(2.2) = 3 and ceiling(2.8) =3
Assume that the file system has H number of hard links. The number of hard links that exist in a file system
can be found by using the UNIX find command. The amount of data that will be written to the disk for
creating the hard links metadata file is (ceiling((H*12)/(4*1024)) * 4) KB
Therefore the minimum mount of data that will be written to the disk for updating the i2p information is
[(ceiling((Used inodes/21))* 4) + (ceiling((H*12)/(4*1024)) * 4) ] KB
The maximum amount of data that might be written to the disk is
[(ceiling((Total inodes possible in the volume/21))* 4) +
(ceiling((H*12)/(4*1024)) * 4) ] KB

4 Inode To Pathname (i2p) feature of Data ONTAP

VOLUME SNAPMIRROR
Volume SnapMirror is an efficient data replication product that transfers only the modified data disk blocks to
the destination after the initial base transfer. Volume SnapMirror transfers data in 4KB disk blocks, and each
disk block holds 21 inodes. The exact amount of the data transferred depends on the distribution of inode
file blocks on the disk and is the same as the amount of data written to the disk stated earlier.
The minimum amount of data that will be transferred due to the i2p updates to the inodes is equal to
ceiling((Used inodes/21)) * 4 KB
The maximum amount of data that might be transferred due to the i2p updates to the inodes is equal to
ceiling((Total inodes possible in the volume/21)) * 4 KB
The amount of data that will be transferred for the hard links metadata file is
ceiling((H*12)/(4*1024)) * 4 KB
The minimum amount of i2p related data that will be transferred to the destination is equal to
[(ceiling((Used inodes/21))* 4) + (ceiling((H*12)/(4*1024)) * 4) ] KB
The maximum amount of i2p related data that might be transferred to the destination is equal to
[(ceiling((Total inodes possible in the volume /21))* 4) +
(ceiling((H*12)/(4*1024)) * 4) ] KB

QTREE SNAPMIRROR AND SNAPVAULT

Qtree SnapMirror enables replication of the source volume or qtree to a destination qtree. SnapVault is a
product for protecting data against loss and preserving old versions of data. SnapVault replicates data in
primary system paths to qtrees on a SnapVault secondary storage system. SnapVault uses the qtree
replication engine to perform replication. Therefore the i2p feature has similar impact on both of these
utilities.
Qtree SnapMirror operates at the logical level and therefore sends only the changed data for each file to the
destination. Each inode is sent in a 4KB header block followed by the updated data blocks for the file (if
any). So the i2p related data transferred to the destination is equal to (Used inodes *4) KB
For both volume and qtree SnapMirror, the i2p data might be transferred to the destination either during a
single SnapMirror update or during multiple SnapMirror updates, depending on the i2p scan finish time and
the SnapMirror update schedule.

5 DATA ONTAP USER INTERFACE

The i2p feature is enabled by default on all volumes after upgrading to Data ONTAP7.1 or later. The i2p
scan starts in the background after the upgrade. The i2p scan functionality in Data ONTAP is controlled by
the volume-level option no_i2p. It is off by default, which means that i2p is enabled.
The following CLI commands can be used to change or modify the options.
CHECK I2P STATUS
To see the current status of i2p on a volume, run the vol options command. no_i2p=off means that
i2p is enabled on the volume:
netapp01> vol options vol0
root, diskroot, nosnap=off, nosnapdir=off, minra=off,
no_atime_update=off, raidtype=raid4, raidsize=8, nvfail=off,
snapmirrored=off, resyncsnaptime=60, create_ucode=off,
convert_ucode=off, maxdirsize=2621, fs_size_fixed=off, svo_enable=off,
svo_checksum=off, svo_allow_rman=off, svo_reject_errors=off,
no_i2p=off, fractional_reserve=100, extent=off

DISABLING AND ENABLING I2P

To disable i2p for a volume, run the following command:
vol options some_vol_name no_i2p on
Since i2p is now disabled, the i2p scanner will not restart until i2p is reenabled on the volume. Disabling i2p
on the volume also aborts the scan even if a scan is currently in progress. Contact NetApp Global Services
before disabling i2p, because it might have an impact on the efficiency and performance of the storage
system.

5 Inode To Pathname (i2p) feature of Data ONTAP

To enable i2p for a volume, run the following command:
vol options some_vol_name no_i2p off
The commands can be used to disable or enable i2p either immediately after upgrade to Data ONTAP 7.1 or
during normal storage system operation.

ADVANCED I2P COMMANDS

The following advanced privilege mode commands can be used to work with the i2p scanner.
Important: Contact NetApp Global Services before using any of the advanced mode commands described
in this section.
You can enter advanced privilege mode by using the Data ONTAP priv command:
netapp01> priv set advanced
netapp01*>
An asterisk (*) is appended to the storage system prompt to reflect that fact that its at the advanced
privilege level.
Use the priv command to return to the default admin priv level:
netapp01*> priv set admin
netapp01>
The wafl scan speed command can be used to alter the speed of all WAFL scans, including the i2p
scan.
The following command prints the current speed set for all scanners:
netapp01*> wafl scan speed
WAFL scan speed is 2000
The speed can be altered by using the same command:
netapp01*> wafl scan speed new_scan_speed
This command gets a list of all WAFL scans and identifies all of the i2p scans running:
netapp01*> wafl scan status
This command prints a list of all scans running on the system on a per volume basis. The i2p scans can be
identified by the scan type inode to parent initialization.
netapp01*> wafl scan status
Volume vol_1:
Scan id Type of scan progress
44 inode to parent initialization 5074 of 207984
To abort an i2p scan on any particular volume, use the following command:
netapp01*> wafl scan abort i2p_scan_id
The i2p_scan_id is the scan ID obtained from the output of the wafl scan status command. Therefore,
in the example, the command to abort i2p scan on vol_1 would be:
netapp01*> wafl scan abort 44
Stopping the i2p scan in this way does not disable i2p on the volume. The next time the volume is brought
online, the i2p scan restarts on this volume.

6 Inode To Pathname (i2p) feature of Data ONTAP

 Aborting an i2p scanner that is currently in progress results in some of the inodes not having the i2p
information in them. This has no negative impact on system functionality in Data ONTAP 7.1. Some of the
system features discussed earlier will be slower. Also, the external applications listed earlier that rely on i2p-
generated data will cease to function.

LIST I2P INFORMATION

The current i2p information present in an inode can be obtained by using the inodepath command. The
inodepath help command on the system gives detailed information about this command.
To lists all possible paths:
netapp01*> inodepath v vol0 -a 1304
Inode 1304 in volume vol0 (fsid 0xbd9a9f3e) has 2 names.
Volume UUID is: 7e8bc5aa-7d4b-11d9-b8ba-000100000abc
[ 1] Primary pathname = /vol/vol0/etc/registry
[ 2] pathname = /vol/vol0/etc/registry.0

6 CONCLUSION
The information provided by the Data ONTAP i2p feature is used by a variety of external applications as well
as internal operations. The i2p feature also forms the basis for some of the Data ONTAP enhancements that
were introduced in releases after Data ONTAP 7.1. The i2p scan that happens in the background after
upgrade and its impact on other features of Data ONTAP is a one-time event and has minimal impact on
system performance.
For more information about the feature, contact your NetApp systems engineer.

2008 NetApp. All rights reserved. Specifications are subject to change without notice. NetApp, the NetApp logo, Go further, faster,
Data ONTAP, SnapMirror, Snapshot, SnapVault, and WAFL are trademarks or registered trademarks of NetApp, Inc. in the United States
and/or other countries. UNIX is a registered trademark of The Open Group. All other brands or products are trademarks or registered
trademarks of their respective holders and should be treated as such. TR-3679
www.netapp.com