UFS is the default disk-based file system in Solaris operating system. Most often, when you administer a disk-based file system, you will be administering UFS file systems. UFS provides the following features:
For detailed information about the UFS file system structure, see Chapter 21, UFS File System (Reference).
When laying out file systems, you need to consider possible conflicting demands. Here are some suggestions:
Distribute the work load as evenly as possible among different I/O systems and disk drives. Distribute the /export/home file system and swap space evenly across disks.
Keep pieces of projects or members of groups within the same file system.
Use as few file systems per disk as possible. On the system (or boot) disk, you should have three file systems: root (/), /usr, and swap space. On other disks, create one or, at most, two file systems; one being additional swap space, preferably. Fewer, roomier file systems cause less file fragmentation than many small, over-crowded file systems. Higher-capacity tape drives and the ability of the ufsdump command to handle multiple volumes make it easier to back up larger file systems.
If you have some users who consistently create very small files, consider creating a separate file system with more inodes. However, most sites do not need to keep similar types of user files in the same file system.
For information on default file system parameters as well as procedures for creating new UFS file systems, see Chapter 16, Creating UFS, TMPFS, and LOFS File Systems (Tasks).
UFS logging bundles the multiple metadata changes that make up a complete UFS operation into a transaction. Sets of transactions are recorded in an on-disk log, and then applied to the actual UFS file system's metadata.
At reboot, the system discards incomplete transactions, but applies the transactions for completed operations. The file system remains consistent because only completed transactions are ever applied. This consistency remains even when a system crashes, which normally interrupts system calls and introduces inconsistencies into a UFS file system.
UFS logging provides two advantages:
If the file system is already consistent due to the transaction log, you might not have to run the fsck command after a system crash or an unclean shutdown. For more information on unclean shutdowns, see What the fsck Command Checks and Tries to Repair.
Starting in the Solaris 9 12/02 release, the performance of UFS logging improves or exceeds the level of performance of non-logging file systems. This improvement can occur because a file system with logging enabled converts multiple updates to the same data into single updates, and so reduces the number of overhead disk operations required.
The log is allocated from free blocks on the file system, and it is sized at approximately 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes. The log is continually flushed as it fills up. The log is also flushed when the file system is unmounted or as a result of any lockfs command.
UFS logging is enabled by default for all UFS file systems.
If you need to disable UFS logging, add the nologging option to the file system's entry in the /etc/vfstab file or when you mount the file system manually.
If you need to enable UFS logging, specify the -o logging option with the mount command in the /etc/vfstab file or when you mount the file system manually. Logging can be enabled on any UFS file system, including the root (/) file system. Also, the fsdb command now has new debugging commands to support UFS logging.
In some operating systems, a file system with logging enabled is known as a journaling file system.
You can use the fssnap command to create a read-only snapshot of a file system. A snapshot is a file system's temporary image that is intended for backup operations.
See Chapter 24, Using UFS Snapshots (Tasks) for more information.
Direct I/O is intended to boost bulk I/O operations. Bulk I/O operations use large buffer sizes to transfer large files (larger than 256 Kbytes).
Using UFS direct I/O might benefit applications, such as database engines, that do their own internal buffering. Starting with the Solaris 8 1/01 release, UFS direct I/O has been enhanced to allow the same kind of I/O concurrency seen when accessing raw devices. Now you can get the benefit of file system naming and flexibility with very little performance penalty. Check with your database vendor to see if they can enable UFS direct I/O in their product configuration options.
Direct I/O can also be enabled on a file system by using the forcedirectio option to the mount command. Enabling direct I/O is a performance benefit only when a file system is transferring large amounts of sequential data.
When a file system is mounted with this option, data is transferred directly between a user's address space and the disk. When forced direct I/O is not enabled for a file system, data transferred between a user's address space and the disk is first buffered in the kernel address space.
The default behavior is no forced direct I/O on a UFS file system. For more information, see mount_ufs(1M).