UFS File System Bugs

Using the UFS noatime and logging Mount Options Can Result in File System Corruption (4884138)

If the UFS noatime and logging mount options are used together, the file system can become corrupted because an inode is not being written. This failure can result in the display of the following messages:

/mnt: unexpected allocated inode 1783, run fsck(1M)...
/zoot: unexpected free inode 5674, run fsck(1M)...

Workaround: Perform the following steps:

1. Determine which file systems are using the noatime and logging mount options.

   % mount | grep noatime | grep logging

2. Edit /etc/vfstab to remove the noatime option from all file systems that use the logging option.

3. Unmount and run the fsck command against all the file systems that were mounted by using the logging and noatime mount options.

4. Run the fsck command against any currently unmounted file systems that were previously mounted with the logging and noatime mount options.

The fsck command might display messages that are similar to the following:

8016 DUP I=646
EXCESSIVE DUP BLKS I=7404
INCORRECT BLOCK COUNT I=7407
DUP/BAD  I=646  OWNER=root MODE=100644
ZERO LENGTH DIRECTORY  I=3807
BAD/DUP FILE I=575  OWNER=root MODE=100644
BAD/DUP DIRECTORY I=3807  OWNER=root MODE=40755
LINK COUNT DIR I=3806  OWNER=root MODE=40755
LINK COUNT FILE I=25084  OWNER=host1 MODE=100644
FREE BLK COUNT(S) WRONG IN SUPERBLK

SPARC: Using fssnap on a Multiterabyte UFS File System Does Not Work (4836824)

Using the fssnap command to create a snapshot of a UFS file system that is greater than 1 Tbyte in size is not supported in the Solaris 9 8/03 release. The following error message is displayed:

fssnap: Fatal: File system /dir/snapshot0 support large files.

Workaround: None.