UFS File System Features

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.

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.

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:

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:

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:

When logging is explicitly disabled.

If there is insufficient file system space for the log.

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.
#

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 space, up to 256 Mbytes. The log size might be larger, up to
a maximum of 512 Mbytes, if the file system has a large number of cylinder
groups.

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.

UFS Direct Input/Output (I/O)

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).