Home > Veritas Storage Foundation™ File System Manual Pages
FSCDSCONV (1M) |
Maintenance Commands |
fscdsconv [ -y | -n ] -i -f recovery_file special
fscdsconv -r -f recovery_file special
fscdsconv -v [ -t target_specifiers ] special
The metadata of the file system is stored in the native byte order of the system on which it was created. To be able to access a file system created on a system with a different byte order, the file system's byte order must first be converted to the native byte order of the system from which it will be accessed. If the source and destination systems for the file system migration differ in byte order, the file system will be byteswapped as part of the fscdsconv operation.
In cases where byteswapping is required to make the file system usable on the target system, you will be prompted to confirm the operation before fscdsconv modifies the file system. If you choose not to proceed with the operation, the file system is left unchanged.
If the file system has any files that might violate the known maximum file size or maximum UID or GID limits on the target file system, such violations are reported as part of the export and import operation. Symantec recommends that you rectify these violations before proceeding with the migration to ensure that the file system is fully usable on the target machine.
The process of converting a file system's byte order can fail for various reasons, such as system failure, power failure, command failures, or user interruption. fscdsconv creates a recovery file as specified by the -f option so that the file system can be restored to its original condition in the event of a failure. In the case of a failure, fscdsconv must be reinvoked with the -r option.
The file system that contains the recovery file must not be a temporary file system that might be cleaned up after a system reboot or whose data integrity is less than the data integrity of the file system being converted. For example, if the file system being converted is on a mirrored volume, the recovery file should also be on a file system that is capable of tolerating disk failures. The recovery file is not removed by fscdsconv when the conversion completes.
See the Veritas Storage Foundation Cross-Platform Data Sharing Administrator's Guide for more information.
The file system to be migrated must be unmounted before performing the conversion.
If quotas will be used on the file system, before unmounting it, remove the quotas and quotas.grp files, which are in the file system root directory. Unmount the file system, then use fscdsconv to convert the file system. On the system to which the file system is being migrated, mount the file system with quotas turned off. See the vxquotaoff(1M) manual page. Edit the quotas and quotas.grp files to input the usage limits, then turn on quotas for the file system. See the vxedquota(1M) and vxquotaon(1M) manual pages.
The fscdsconv command validates the file system to determine if there are any files that violate the known maximum limits of file size, UID, or GID on the target system, reports any such violations, and waits for user confirmation before proceeding. If any violations are reported, Symantec recommends that you abort the migration, rectify the violations, then restart the migration.
If the file system metadata must be byteswapped for use on the specified target, fscdsconv waits for user confirmation before proceeding with the migration.
After the export is complete and reported to be successful, the file system is ready for use on the target. If byteswapping was done as part of the export, the file system will no longer be accessible on the source machine.
If the file system metadata needs to be byteswapped for use on the system, the fscdsconv command waits for user confirmation before proceeding with the migration.
os_name=os_name[,os_rel=os_release][,arch=arch][,vxfs_vers=vxfs_version][,bits=bits]
- os_name=os_name
- Specifies the name of the target operating system to which the file system is planned to be migrated. os_name can have a value of AIX-UX, HP-UX, Linux, or SunOS. os_name must be specified if the target is specified.
- os_rel=os_release
- Specifies the operating system release version of the target, such as 5.8, 5.9, or 5.10 for SunOS.
- arch=arch
- Specifies the architecture of the target, such as x86 or sparc for SunOS.
- vxfs_vers=vxfs_version
- Specifies the VxFS release version that is in use on the target, such as 4.1 or 5.0.
- bits=bits
- Specifies the kernel bits of the target. bits can have a value of 32 or 64 to indicate whether the target is running a 32-bit kernel or 64-bit kernel.
While os_name must be specified for all fscdsconv invocations that permit the target to be specified, all other target specifiers are optional and are available for the user to fine-tune the migration target specification. If the values for the optional target specifiers are not specified, fscdsconv will choose the defaults for the specified target based on the information available in the limits file that best fits the specified target, and proceed with the CDS operation. The chosen defaults are displayed to the user before proceeding with the migration.
# fscdsconv -e -t os_name=HP-UX -f /fs2/recovery1 /dev/vx/rdsk/dg1/fs1
The following command recovers the file system /dev/vx/rdsk/dg1/fs1 after a failure, using the recovery file recovery1 located on the file system fs2:
# fscdsconv -r -f /fs2/recovery1 /dev/vx/rdsk/dg1/fs1
The following command validates the file system /dev/vx/rdsk/dg1/fs1 for the Linux target. Since the byte order is the same on both the source and the target, there is no need for a byte order conversion. As such, the recovery file, /fs2/recovery1, is not used:
# fscdsconv -e -t os_name=Linux -f /fs2/recovery1 /dev/vx/rdsk/dg1/fs1
The following command imports the file system /dev/vx/rdsk/dg1/fs1 for use on the current system and creates the recovery file /fs2/recovery1 if a byte order conversion is required:
# fscdsconv -i -f /fs2/recovery1 /dev/vx/rdsk/dg1/fs1
Veritas Storage Foundation Cross-Platform Data Sharing Administrator's Guide
Last updated: 7 May 2007
Copyright ©2009 Symantec Corporation
All rights reserved.