UFS File System
UFS is the default disk-based file system in Solaris OS. Most often, when
you administer a disk-based file system, you are administering UFS file systems. UFS
provides the following features.
UFS Feature |
Description |
|---|
Extended fundamental types (EFT) |
Provides 32-bit user ID (UID),
group ID (GID), and device numbers. |
Large file systems |
Allows files of about 1
terabyte in size in a file system that can be up to
16 terabytes in size. You can create a multiterabyte UFS file system on
a disk with an EFI disk label. |
Logging |
UFS logging bundles the multiple metadata changes
that comprise a complete UFS operation into a transaction. Sets of transactions are
recorded in an on-disk log and are applied to the actual UFS file
system's metadata. |
Multiterabyte file systems |
A multiterabyte file system enables creation of a UFS
file system up to approximately 16 terabytes of usable space, minus approximately
one percent overhead |
State flags |
Shows the state of the file system: clean, stable, active,
logging, or unknown. These flags eliminate unnecessary file system checks. If
the file system is “clean,” “stable,” or “logging,” file system checks are not run.
|
For detailed information about the UFS file system structure, see Chapter 23, UFS File System (Reference).
Planning UFS File Systems
When laying out file systems, you need to consider possible conflicting demands.
Here are some suggestions:
Distribute the workload 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, with one file system preferrably being additional swap space. 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 18, Creating UFS, TMPFS, and LOFS File Systems (Tasks).
64-bit: Support of Multiterabyte UFS File Systems
This Solaris release provides support for multiterabyte UFS file systems on systems that run
a 64-bit Solaris kernel.
Previously, UFS file systems were limited to approximately 1 terabyte on both 64-bit
and 32-bit systems. All UFS file system commands and utilities have been updated
to support multiterabyte UFS file systems.
For example, the ufsdump command has been updated with a larger block size
for dumping large UFS file systems:
# ufsdump 0f /dev/md/rdsk/d97 /dev/md/rdsk/d98
DUMP: Date of this level 0 dump: Tue Jan 07 14:23:36 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d98 to /dev/md/rdsk/d97.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Forcing larger tape block size (2048).
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 4390629500 blocks (2143862.06MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
Administering UFS file systems that are less than 1 terabyte remains the same.
No administration differences exist between UFS file systems that are less than one
terabyte and file systems that are greater than 1 terabyte.
You can initially create a UFS file system that is less than
1 terabyte and specify that it can eventually be expanded into a multiterabyte
file system by using the newfs -T option. This option sets the inode and
fragment density to scale appropriately for a multiterabyte file system.
Using the newfs -T option when you create a UFS file system less
than 1 terabyte on a system running a 32-bit kernel enables you to
eventually expand this file system by using the growfs command when you
boot this system under a 64-bit kernel. For more information, see newfs(1M).
You can use the fstyp -v command to identify whether a UFS file
system has multiterabyte support by checking the following value in the magic column:
# /usr/sbin/fstyp -v /dev/md/rdsk/d3 | head -5
ufs
magic decade format dynamic time Fri May 21 11:10:10 2004
A UFS file system with no multiterabyte support has the following fstyp
output:
# /usr/sbin/fstyp -v /dev/md/rdsk/d0 | head -5
ufs
magic 11954 format dynamic time Fri May 21 11:46:40 2004
You can use the growfs command to expand a UFS file system to
the size of the slice or the volume without loss of service
or data. For more information, see growfs(1M).
Two new related features are multiterabyte volume support with the EFI disk label
and multiterabyte volume support with Solaris Volume Manager. For more information, see EFI Disk Label
and the Solaris Volume Manager Administration Guide.
Features of Multiterabyte UFS File Systems
Multiterabyte UFS file systems include the following features:
Provides the ability to create a UFS file system up to 16 terabytes in size.
Provides the ability to create a file system less than 16 terabytes that can later be increased in size up to 16 terabytes.
Multiterabyte file systems can be created on physical disks, Solaris Volume Manager's logical volumes, and Veritas' VxVM logical volumes.
Multiterabyte file systems benefit from the performance improvements of having UFS logging enabled. Multiterabyte file systems also benefit from the availability of logging because the fsck command might not have to be run when logging is enabled.
When you create a partition for your multiterabyte UFS file system, the disk will be labeled automatically with an EFI disk label. For more information on EFI disk labels, see EFI Disk Label.
Provides the ability to snapshot a multiterabyte file system by creating multiple backing store files when a file system is over 512 Gbytes.
Limitations of Multiterabyte UFS File Systems
Limitations of multiterabyte UFS file systems are as follows:
This feature is not supported on 32-bit systems.
You cannot mount a file system greater than 1 terabyte on a system that is running a 32-bit Solaris kernel.
You cannot boot from a file system greater than 1 terabyte on a system that is running a 64-bit Solaris kernel. This limitation means that you cannot put a root (/) file system on a multiterabyte file system.
There is no support for individual files greater than 1 terabyte.
The maximum number of files is 1 million files per terabyte of a UFS file system. For example, a 4-terabyte file system can contain 4 million files.
This limit is intended to reduce the time it takes to check the file system with the fsck command.
The maximum quota that you can set on a multiterabyte UFS file system is 2 terabytes of 1024-byte blocks.
Where to Find Multiterabyte UFS Tasks
Use these references to find step-by-step instructions for working with multiterabyte UFS file
systems.
UFS Logging
UFS logging bundles the multiple metadata changes that comprise a complete UFS operation into
a transaction. Sets of transactions are recorded in an on-disk log. Then, they
are 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. A system crash might interrupt
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. Thus, reduces the number of overhead disk operations required.
Logging is enabled by default for all UFS file systems, except under the
following conditions:
In previous Solaris releases, you had to manually enable UFS logging.
Keep the following issues in mind when using UFS logging:
Ensure that you have enough disk space for your general system needs, such as for users and applications, and for UFS logging.
If you don't have enough disk space for logging data, a message similar to the following is displayed:
# mount /dev/dsk/c0t4d0s0 /mnt
/mnt: No space left on device
Could not enable logging for /mnt on /dev/dsk/c0t4d0s0.
#
However, the file system is still mounted. For example:
# df -h /mnt
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t4d0s0 142M 142M 0K 100% /mnt
#
A UFS file system with logging enabled that is generally empty will have some disk space consumed for the log.
If you upgrade to this Solaris release from a previous Solaris release, your UFS file systems will have logging enabled, even if the logging option was not specified in the /etc/vfstab file. To disable logging, add the nologging option to the UFS file system entries in the /etc/vfstab file.
The UFS transaction log has the following characteristics:
Is allocated from free blocks on the file system
Sized at approximately 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes
Continually flushed as it fills up
Also flushed when the file system is unmounted or as a result of any lockfs command.
If you need to enable UFS logging, specify the -o logging option with the
mount command in the /etc/vfstab file or when you manually mount the file
system. Logging can be enabled on any UFS file system, including the root
(/) file system. Also, the fsdb command 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.
UFS Snapshots
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 26, Using UFS Snapshots (Tasks) for more information.
UFS Direct Input/Output (I/O)
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 that
occurs when raw devices are accessed. 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 it can enable UFS direct I/O in
its 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).
