|
|
|
|
|
The following issues were reported for this release of Veritas File System.
VxFS now implements the quota Application Program Interface (API) documented in the Solaris quotactl(7I) manual page. Users who have written their own quota tools based on the Q_QUOTACTL ioctl can now use those tools on VxFS file systems. However, you cannot administer VxFS file system quotas using the Q_QUOTACTL ioctl from a client which mounts VxFS over NFS. This capability will not be available until a modification to the RPC quota daemon (enabling quotas on file systems other than UFS) is implemented on the Solaris operating system.
When installed on Solaris 8, Solaris 9, and Solaris 10, VxFS changes the default stack size to 24K for 64-bit systems. In 32-bit mode, VxFS can operate with a stack size of 16K. The stack size is designated in the Solaris configuration file /etc/system.
Storage Checkpoints cannot be created on a file system where the Veritas Storage Migrator™ is active, or with other hierarchical storage management (HSM) products that use the DMAPI interface.
VxFS does not operate with Veritas Storage Migrator versions 4.5 and earlier. A patch for Veritas Storage Migrator 4.5 is available from Veritas support on the Veritas Customer Support website:
http://support.veritas.com/docs/258566.htm
Other HSM applications may also require a patch. Contact your HSM vendor for product-specific information.
The ustat command returns an EOVERFLOW error for VxFS files systems larger than one terabyte because the variable used to store file system size overflows. See the ustat(2) manual page.
For utilities to operate correctly on large-file systems, they must be large file aware. This applies even if commands are invoked on small files in a large file system. See the information regarding disk layout in the Veritas File System Administrator's Guide.
For a file system to have more than 8 million inodes, you must create it using the largefiles option of mkfs (the fsadm utility can also be used to set the largefiles flag on the file system). See the mkfs_vxfs(1M) and fsadm_vxfs(1M) manual pages for details. The largefiles option is enabled by default on VxFS 4.1. In previous VxFS releases, nolargefiles was the default mount option.
Ioctls are not supported on the File Change Log file. Therefore, running commands such as fsapadm, setext, fiostat, and fsmap on the FCL file is not supported since these commands use an internal ioctl to implement their functionality.
When a file system is mounted, VxFS keeps certain data structures in the kernel. As the size of the file system increases, the amount of data structures stored by VxFS also increases. The file system typically keeps approximately 128 bytes per allocation unit (32,768 file system blocks). This translates to a usage of 512K per 1 TB for an 8K block size file system (4 MB per 1 TB for a 1K block size file system). Therefore, large file systems must be mounted only on systems that have sufficient memory. The memory requirements for mounting large file systems are shown in the tables below.
While performing a full fsck, the system keeps certain data structures in the core for validating the space usage and inode usage. The space needed depends on the number of inodes and the number of blocks in the file system. The fsck command needs approximately 16 MB per 1 TB for an 8K block size file system (128 MB per 1 TB for a 1K block size file system) and 32 MB per million inodes. Sufficient memory and swap space should be configured on the system before running a full fsck on a large file-enabled system. If the system is booted through a 32-bit kernel, a full fsck of file systems that have a large number of blocks or large number of inodes may fail, as the total address space available for a 32-bit process is limited.
A replay fsck does not need a significant amount of memory and does not have these issues.
If you try to convert a sparse file to a Quick I/O file, the Oracle instance can fail if Oracle tries to write into an unallocated block. Specifically, datafiles used by the Oracle8i and Oracle9i temporary tablespace may be sparse files, so do not convert these to Quick I/O files. See the Veritas Storage Foundation 4.1 for Oracle Database Administrator's Guide for more information.
When VxFS file systems are exported via NFS, quotas on the file system apply to users when accessing the file system from NFS clients. However, neither the Solaris nor the VxFS quota commands on the NFS client can be used to query or edit quotas. The VxFS quota commands can be used on the server to query or edit quotas.
The fscdstask validate command returns an error when files on the specified mount point have names with the jp_JP.UTF-8 encoding, but the locale has been changed to ja_JP.eucJP or ja_JP.PCK. The error is as follows:
xargs: Input file is corrupt. : Incorrect byte order
Files should be created with the same locale encoding as the file system on which they reside.
The output of the ls -l command on VxFS file systems shows mask/CLASS_OBJ in place of group permissions if ACLs are in use on a file or a directory. You can determine the effective group permissions by using the getfacl command.
The chmod command changes mask/CLASS_OBJ instead of the group permissions if ACLs are in use on a file or a directory. GROUP_OBJ is not changed by chmod, and because effective group permissions are determined by GROUP_OBJ and CLASS_OBJ, the default group may not receive the permissions specified by chmod. Because ls -l shows mask only (which is changed by chmod), it only appears that the group permissions are changed as specified in chmod. On files with ACLs, use the setfacl command to manipulate permissions. On Solaris 9, the ls command displays these permissions the same way on UFS and VxFS.
See the following manual pages for ACL-related information: aclcheck(3), aclsort(3), chmod(1), getfacl(1), ls(1), setfacl(1), and umask(1).
In some circumstances, the fsadm and fsvoladm commands cannot resize a 100% full file system due to lack of space for updating structural information. Check VxFS file systems on a regular basis and increase their size if they approach 100% capacity. This problem can also occur if the file system is very busy. Free up space or reduce activity on the file system and try the resize again.
The JumpStart Enterprise Toolkit is not supported in this release, but will be supported in the next release.
On the Solaris 10 operating system, DTrace warnings may display when the system is booted for the first time after VxFS is installed. The warnings are similar to the following:
Hostname: MyHost.MyCompany.com
WARNING: couldn't allocate SDT table for module vxfs
WARNING: couldn't allocate SDT table for module vxfs
WARNING: couldn't allocate FBT table for module vxfs
Loading smf(5) service descriptions: 2/2
These warnings indicate that the SDT and FBT DTrace probes may not be available for the vxfs module until the next reboot. The vxfs module will still load and work correctly.
These warnings do not display on subsequent reboots.
The following known issues were reported for this release:
Due to an incompatibility in the VxFS fsck utility between the 5.0 and 4.0 and 4.1 releases, fsck may terminate during intent log replay if run on older file systems. This only affects file systems that were previously running under VxFS 4.0 or 4.1 that are CVM-shared volumes or multi-volume file systems, and that were not cleanly unmounted prior to use in VxFS 5.0.
If you encounter this situation, perform a full fsck to bring the file system to a consistent, clean state that is ready to be mounted.
See the fsck_vxfs(1M) manual page.
After the value for fcl_keeptime has been modified to a non-default value through the vxtunefs command, you cannot reset the value back to the default value of 0.
Certain file system metadata that is only in the file system must be allocated from volume 0. If volume 0 is full, operations such as upgrading the file system's disk layout version and creating a Storage Checkpoint can fail. These operations can be retried after freeing space on volume 0.