 | ||
| Storage Checkpoint visibility | ||
|---|---|---|
| Prev | How a Storage Checkpoint works | Next |
With the ckptautomnt mount option, all Storage Checkpoints are made accessible automatically through a directory in the root directory of the file system that has the special name .checkpoint, which does not appear in directory listings. Inside this directory is a directory for each Storage Checkpoint in the file system. Each of these directories behave as a mount of the corresponding Storage Checkpoint, with the following exceptions:
External applications, such as NFS, see the files as part of the original mount point. Thus, no additional NFS exports are necessary.
Inode numbers exposed to applications can be made unique, depending on a mount option.
The Storage Checkpoints are automounted internally, but the operating system does not know about the automounting. This means that Storage Checkpoints cannot be mounted manually, and they do not apear in the list of mounted file systems. When Storage Checkpoints are created or deleted, entries in the Storage Checkpoint directory are automatically updated. If a Storage Checkpoint is removed with the -f option while a file in the Storage Checkpoint is still in use, the Storage Checkpoint is force unmounted, and all operations on the file fail with the EIO error.
If there is already a file or directory named .checkpoint in the root directory of the file system, such as a directory created with an older version of Veritas File System (VxFS) or when Storage Checkpoint visibility feature was disabled, the fake directory providing access to the Storage Checkpoints is not accessible. With this feature enabled, attempting to create a file or directory in the root directory with the name .checkpoint fails with the EEXIST error.
The inode number of a file is the same across Storage Checkpoints. For example, if the file file1 exists in a file system and a Storage Checkpoint is taken of that file system, running the stat command on file1 in the original file system and in the Storage Checkpoint returns the same value in st_ino. The combination of st_ino and st_dev should uniquely identify every file in a system. This is usually not a problem because Storage Checkpoints get mounted separately, so st_dev is different. When accessing files in a Storage Checkpoint through the Storage Checkpoint visibility extension, st_dev is the same for all Storage Checkpoints as well as for the original file system. This means files can no longer be identified uniquely by st_ino and st_dev.
In general, uniquely identifying all files in a system is not necessary. However, there can be some applications that rely on unique identification to function properly. For example, a backup application might check if a file is hard-linked to another file by calling stat on both and checking if st_ino and st_dev are the same. If a backup application were told to back up two clones through the Storage Checkpoint visibility extension at the same time, the application can erroneously deduce that two files are the same even though the files contain different data.
By default, Veritas Storage Foundation (SF) does not make inode numbers unique. However, you can specify the uniqueino mount option to enable the use of unique 64-bit inode numbers. You cannot change this option during a remount.