< Previous | Next > | |
Product: File System Guides | |
Manual: File System 4.1 Administrator's Guide |
Storage Checkpoint AdministrationStorage Checkpoint administrative operations require the fsckptadm utility (see the fsckptadm(1M) manual page). You can use the fsckptadm utility to create and remove Storage Checkpoints, change attributes, and ascertain statistical data. Every Storage Checkpoint has an associated name, which allows you to manage Storage Checkpoints; this name is limited to 127 characters and cannot contain a colon (:). Storage Checkpoints require some space for metadata on the volume or set of volumes specified by the file system allocation policy or Storage Checkpoint allocation policy. The fsckptadm utility displays an error if the volume or set of volumes does not have enough free space to contain the metadata. You can roughly approximate the amount of space required by the metadata using a method that depends on the disk layout version of the file system. For disk layout Version 5 or prior, multiply the number of inodes (# of inodes) by the inode size (inosize) in bytes, and add 1 or 2 megabytes to get the approximate amount of space required. You can determine the number of inodes with the fsckptadm utility, and the inode size with the mkfs command: # fsckptadm -v info '' /mnt0 UNNAMED: ctime = Thu 3 Mar 2005 7:00:17 PM PST mtime = Thu 3 Mar 2005 7:00:17 PM PST flags = largefiles, mounted # of inodes = 23872 # of blocks = 27867 . . . # of overlay bmaps = 0 # mkfs -m /mnt0 mkfs -F vxfs -o bsize=1024,version=6,inosize=256,logsize=16384, largefiles /mnt0 In this example, the approximate amount of space required by the metadata is 7 or 8 megabytes (23,872 x 256 bytes, plus 1 or 2 megabytes). For disk layout Version 6, multiply the number of inodes by 1 byte, and add 1 or 2 megabytes to get the approximate amount of space required. You can determine the number of inodes with the fsckptadm utility as above. Using the output from the example for disk layout Version 5 or prior, the approximate amount of space required by the metadata is just over one or two megabytes (23,872 x 1 byte, plus 1 or 2 megabytes). Use the fsvoladm command to determine if the volume set has enough free space (see the fsvoladm(1M) manual page): # fsvoladm list /mnt0 devid size used avail name 0 20971520 8497658 12473862 mnt1 1 20971520 6328993 14642527 mnt2 2 20971520 4458462 16513058 mnt3 Creating a Storage CheckpointYou can create a Storage Checkpoint using the fsckptadm utility. In these examples, /mnt0 is a mounted VxFS file system with a Version 4 or Version 5 disk layout. This example shows the creation of a nodata Storage Checkpoint (see Space Management Considerations) named thu_7pm on /mnt0 and lists all Storage Checkpoints of the /mnt0 file system: # fsckptadm -n create thu_7pm /mnt0 # fsckptadm list /mnt0 /mnt0 thu_7pm: ctime = Thu 3 Mar 2005 7:00:17 PM PST mtime = Thu 3 Mar 2005 7:00:17 PM PST flags = nodata, largefiles This example shows the creation of a removable Storage Checkpoint named thu_8pm on /mnt0 and lists all Storage Checkpoints of the /mnt0 file system: # fsckptadm -r create thu_8pm /mnt0 # fsckptadm list /mnt0 /mnt0 thu_8pm: ctime = Thu 3 Mar 2005 8:00:19 PM PST mtime = Thu 3 Mar 2005 8:00:19 PM PST flags = largefiles, removable thu_7pm: ctime = Thu 3 Mar 2005 7:00:17 PM PST mtime = Thu 3 Mar 2005 7:00:17 PM PST flags = nodata, largefiles Removing a Storage CheckpointYou can delete a Storage Checkpoint by specifying the remove keyword of the fsckptadm command. Specifically, you can use either the synchronous or asynchronous method of removing a Storage Checkpoint; the asynchronous method is the default method. The synchronous method entirely removes the Storage Checkpoint and returns all of the blocks to the file system before completing the fsckptadm operation. The asynchronous method simply marks the Storage Checkpoint for removal and causes fsckptadm to return immediately. At a later time, an independent kernel thread completes the removal operation and releases the space used by the Storage Checkpoint. In this example, /mnt0 is a mounted VxFS file system with a Version 4 disk layout. This example shows the asynchronous removal of the Storage Checkpoint named thu_8pm and synchronous removal of the Storage Checkpoint named thu_7pm. This example also lists all the Storage Checkpoints remaining on the /mnt0 file system after the specified Storage Checkpoint is removed: # fsckptadm remove thu_8pm /mnt0 # fsckptadm list /mnt0 /mnt0 thu_7pm: ctime = Thu 3 Mar 2005 7:00:17 PM PST mtime = Thu 3 Mar 2005 7:00:17 PM PST flags = nodata, largefiles # fsckptadm -s remove thu_7pm /mnt0 # fsckptadm list /mnt0 /mnt0 Accessing a Storage CheckpointYou can mount Storage Checkpoints using the mount command (see the mount_vxfs(1M) manual page) with the mount option –o ckpt=ckpt_name. Observe the following rules when mounting Storage Checkpoints:
Caution If you create a Storage Checkpoint for backup purposes, do not mount it as a writable Storage Checkpoint. You will lose the point-in-time image if you accidently write to the Storage Checkpoint. A Storage Checkpoint is mounted on a special pseudo device. This pseudo device does not exist in the system name space; the device is internally created by the system and used while the Storage Checkpoint is mounted. The pseudo device is removed after you unmount the Storage Checkpoint. A pseudo device name is formed by appending the Storage Checkpoint name to the file system device name using the colon character (:) as the separator. For example, if a Storage Checkpoint named may_23 belongs to the file system residing on the special device /dev/vx/dsk/fsvol/vol1, the Storage Checkpoint pseudo device name is: /dev/vx/dsk/fsvol/vol1:may_23 To mount the Storage Checkpoint named may_23 as a read-only (default) Storage Checkpoint on directory /fsvol_may_23, type: # mount -F vxfs -o ckpt=may_23 /dev/vx/dsk/fsvol/vol1:may_23 \ /fsvol_may_23 The /fsvol file system must already be mounted before the Storage Checkpoint can be mounted. To remount the Storage Checkpoint named may_23 as a writable Storage Checkpoint, type: # mount -F vxfs -o ckpt=may_23,remount,rw \ /dev/vx/dsk/fsvol/vol1:may_23 /fsvol_may_23
To mount this Storage Checkpoint automatically when the system starts up, put the following entries in the /etc/fstab file:
To mount a Storage Checkpoint of a cluster file system, you must also use the –o cluster option: # mount -F vxfs -o cluster,ckpt=may_23 \ /dev/vx/dsk/fsvol/vol1:may_23 /fsvol_may_23 You can only mount a Storage Checkpoint clusterwide if the file system that the Storage Checkpoint belongs to is also mounted clusterwide. Similarly, you can only mount a Storage Checkpoint locally if the file system that the Storage Checkpoint belongs to is mounted locally. You can unmount Storage Checkpoints using the umount command (see the umount_vxfs(1M) manual page). Storage Checkpoints can be unmounted by the mount point or pseudo device name: # umount /fsvol_may_23 # umount /dev/vx/dsk/fsvol/vol1:may_23 /dev/vx/dsk/fsvol/vol1 /fsvol vxfs defaults 0 2 /dev/vx/dsk/fsvol/vol1:may_23 /fsvol_may_23 vxfs clone=may_23 0 0 Note You do not need to run the fsck utility on Storage Checkpoint pseudo devices because pseudo devices are part of the actual file system. Converting a Data Storage Checkpoint to a Nodata Storage CheckpointA nodata Storage Checkpoint does not contain actual file data. Instead, this type of Storage Checkpoint contains a collection of markers indicating the location of all the changed blocks since the Storage Checkpoint was created (see Types of Storage Checkpoints for more information). You can use either the synchronous or asynchronous method to convert a data Storage Checkpoint to a nodata Storage Checkpoint; the asynchronous method is the default method. In a synchronous conversion, fsckptadm waits for all files to undergo the conversion process to "nodata" status before completing the operation. In an asynchronous conversion, fsckptadm returns immediately and marks the Storage Checkpoint as a nodata Storage Checkpoint even though the Storage Checkpoint's data blocks are not immediately returned to the pool of free blocks in the file system. The Storage Checkpoint deallocates all of its file data blocks in the background and eventually returns them to the pool of free blocks in the file system. If all of the older Storage Checkpoints in a file system are nodata Storage Checkpoints, use the synchronous method to convert a data Storage Checkpoint to a nodata Storage Checkpoint. If an older data Storage Checkpoint exists in the file system, use the asynchronous method to mark the Storage Checkpoint you want to convert for a delayed conversion. In this case, the actual conversion will continue to be delayed until the Storage Checkpoint becomes the oldest Storage Checkpoint in the file system, or all of the older Storage Checkpoints have been converted to nodata Storage Checkpoints. Note You cannot convert a nodata Storage Checkpoint to a data Storage Checkpoint because a nodata Storage Checkpoint only keeps track of the location of block changes and does not save the content of file data blocks. Difference Between a Data and a Nodata Storage CheckpointThe following example shows the difference between data Storage Checkpoints and nodata Storage Checkpoints. To show the difference between Storage Checkpoints
Conversion with Multiple Storage CheckpointsThe following example highlights the conversion of data Storage Checkpoints to nodata Storage Checkpoints, particularly when dealing with older Storage Checkpoints on the same file system. To convert Storage Checkpoints
|
^ Return to Top | < Previous | Next > |
Product: File System Guides | |
Manual: File System 4.1 Administrator's Guide | |
VERITAS Software Corporation
www.veritas.com |