This section describes all file system features in the Solaris 10 3/05 release that are new or have been enhanced since the Solaris 9 OS was originally distributed in May 2002.
This feature is new in the Software Express pilot program. In the Solaris Express 8/04 release, NFS version 4 became the default. This feature is included in the Solaris 10 3/05 release.
The Solaris 10 OS includes the Sun implementation of the NFS version 4 distributed file access protocol. This version is the next logical step in the evolution of NFS. The NFS version 4 protocol, specified in RFC 3530, was created under the auspices of the Internet Engineering Task Force (IETF). This version is designed to be both vendor neutral and operating system neutral.
NFS version 4 integrates file access, file locking, and mount protocols into a single, unified protocol to ease traversal through a firewall and improve security. The Solaris implementation of NFS version 4 is fully integrated with Kerberos V5, also known as SEAM, thus providing authentication, integrity, and privacy. NFS version 4 also enables the negotiation of security flavors to be used between the client and the server. With NFS version 4, a server can offer different security flavors for different file systems.
The Solaris implementation of NFS version 4 includes delegation, a technique by which the server can delegate the management of a file to a client. This technique can reduce the number of round-trip operations because the client is guaranteed that no modification can occur without the server informing the client. The protocol also includes operation compounding, which allows multiple operations to be combined into a single “over-the-wire” request.
For more information about NFS version 4, refer to Chapter 6, “Accessing Network File Systems (Reference),” in the System Administration Guide: Network Services.
This feature is new in the Solaris Express 4/04 release and in the Solaris 9 9/04 release.
Logging is now enabled by default for all UFS file systems except under the following conditions:
When logging is explicitly disabled
If insufficient file system space exists for the log
In previous Solaris releases, you had to enable UFS logging manually.
UFS logging packages into one transaction the multiple metadata changes that compose a complete UFS operation. Sets of transactions are recorded in an on-disk log, and then applied to the actual UFS file system's metadata.
UFS logging provides two advantages:
If the file system is already consistent because of the transaction log, you might not have to run the fsck command after a system crash or an unclean shutdown.
Starting in the Solaris 9 12/02 release, the performance of UFS logging improves or exceeds the level of performance of nonlogging file systems. This improvement can occur because a file system with logging enabled converts multiple updates to the same data into single updates. This capability reduces the number of overhead disk operations that are required.
For more information, see “What’s New in File Systems in the Solaris 10 Release?” in the System Administration Guide: Devices and File Systems. See also the mount_ufs(1M) man page.
This feature is new in the Software Express pilot program and in the Solaris 9 12/03 release. This feature is included in the Solaris 10 3/05 release.
The following enhancements have improved the performance of the NFS client:
Restrictions on wire transfer sizes have been relaxed. Now, the transfer size is based on the capabilities of the underlying transport. For example, the NFS transfer limit for UDP is still 32 Kbytes. However, because TCP is a streaming protocol without the datagram limits of UDP, maximum transfer sizes over TCP have been increased to 1 Mbyte.
Previously, all write requests were serialized by both the NFS client and the NFS server. The NFS client has been modified to permit an application to issue concurrent writes, as well as concurrent reads and writes, to a single file. You can enable this functionality on the client by using the forcedirectio mount option. When you use this option, you are enabling this functionality for all files within the mounted file system. You could also enable this functionality on a single file on the client by using the directio() interface. Note that unless this new functionality has been enabled, writes to files are serialized. Also, if concurrent writes or concurrent reads and writes are occurring, then POSIX semantics are no longer being supported for that file.
The NFS client no longer uses an excessive number of UDP ports. Previously, NFS transfers over UDP used a separate UDP port for each outstanding request. Now, by default, the NFS client uses only one UDP reserved port. However, this support is configurable. If the use of more simultaneous ports would increase system performance through increased scalability, then the system can be configured to use more ports. This capability also mirrors the NFS over TCP support, which has had this kind of configurability since its inception.
For further information, see the System Administration Guide: Network Services.
Multiterabyte UFS file system support is available only for systems that run a 64-bit kernel. This feature is new in the Software Express pilot program and in the Solaris 9 8/03 release. This feature is included in the Solaris 10 3/05 release.
The Solaris 10 OS 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 (Tbyte) on both 64-bit systems and 32-bit systems. All UFS file system commands and utilities have been updated to support multiterabyte UFS file systems.
You can initially create a UFS file system that is less than one Tbyte. You can specify that the file system can eventually be grown to a multiterabyte file system by using the newfs -T command. This command sets the inode and fragment density to scale appropriately for a multiterabyte file system.
Support for a multiterabyte UFS file system assumes the availability of multiterabyte LUNs. These LUNS are provided as Solaris Volume Manager volumes, or as physical disks that are greater than one Tbyte.
Features of multiterabyte UFS file systems include the following:
You can create a UFS file system to a maximum of 16 Tbytes in size.
You can create a file system that is less than 16 Tbytes, which can later be increased in size to a maximum of 16 Tbytes.
Multiterabyte file systems can be created on physical disks and on Solaris Volume Manager's logical volumes.
UFS logging is enabled by default on file systems greater than 1 Tbyte. 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.
Limitations of multiterabyte UFS file systems include the following:
You cannot mount a file system that is greater than 1 Tbyte on a system that runs a 32-bit Solaris kernel.
You cannot boot from a file system that is greater than 1 Tbyte on a system that runs a 64-bit Solaris kernel. This limitation means that you cannot put a root (/) file system on a multiterabyte file system.
These systems do not support individual files greater than 1 Tbyte.
The maximum number of files per Tbyte of UFS file system is 1 million. 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 Tbytes of 1024–byte blocks.
Using the fssnap command to create a snapshot of a multiterabyte UFS file system is not currently supported.
For more information, see “What’s New in File Systems in the Solaris 10 Release?” in the System Administration Guide: Devices and File Systems.
This feature is new in the Software Express pilot program. This feature is included in the Solaris 10 3/05 release.
The devfs file system manages devices in the Software Express releases. Users continue to access all devices through entries in the /dev directory. These entries are symbolic links to entries in the /devices directory. The content of the /devices directory is now controlled by the devfs file system. The entries in the /devices directory dynamically represent the current state of accessible devices on the system. These entries require no administration.
The devfs file system provides the following enhancements:
Operations in the /devices directory result in attaching device entries. Unused device entries are detached.
System boot performance is increased because only device entries that are needed to boot the system are attached. New device entries are added as the devices are accessed.
For more information, see the devfs(7FS) man page.
This multiterabyte disk support is available only for systems that run a 64-bit kernel. This feature is new in the Software Express pilot program and in the Solaris 9 4/03 release. This feature is included in the Solaris 10 3/05 release.
The Solaris 10 OS provides support for disks that are larger than 1 terabyte (Tbyte) on systems that run a 64-bit Solaris kernel.
The Extensible Firmware Interface (EFI) label provides support for physical disks and virtual disk volumes. The UFS file system is compatible with the EFI disk label, and you can create a UFS file system that is greater than 1 Tbyte. This release also includes updated disk utilities for managing disks that are greater than 1 Tbyte.
However, the SCSI driver, ssd, currently supports disks only up to 2 Tbytes. If you need greater disk capacity than 2 Tbytes, use a disk and storage management product such as Solaris Volume Manager to create a larger device.
For more information on using the EFI disk label, see the System Administration Guide: Devices and File Systems. This guide contains important information and restrictions. This information concerns using the EFI disk label with existing software products.
The Solaris Volume Manager software can also be used to manage disks that are greater than 1 Tbyte in this Solaris release. See Multiterabyte Volume Support in Solaris Volume Manager.
This feature is new in the Software Express pilot program. This feature is included in the Solaris 10 3/05 release.
The new configuration file for your autofs environment, /etc/default/autofs, provides an additional way to configure your autofs commands and autofs daemons. Now, the same specifications that you would make on the command line can be made in this new configuration file. However, unlike the specifications you would make on the command line, this file preserves your specifications, even during upgrades to your operating system. Additionally, you no longer are required to update critical startup files to ensure that the existing behavior of your autofs environment is preserved.
You can make your specifications by using the following keywords:
AUTOMOUNTD_ENV permits you to assign different values to different environments. This keyword is the equivalent of the -D argument for automountd.
AUTOMOUNTD_NOBROWSE turns browsing on, or turns browsing off, for all autofs mount points. This command is the equivalent of the -n argument for automountd.
AUTOMOUNTD_TRACE expands each remote procedure call (RPC) and displays the expanded RPC on standard output. This keyword is the equivalent of the -T argument for automountd.
AUTOMOUNTD_VERBOSE logs status messages to the console and is the equivalent of the -v argument for the automountd daemon.
AUTOMOUNT_TIMEOUT sets the duration for a file system to remain idle before the file system is unmounted. This keyword is the equivalent of the -t argument for the automount command.
AUTOMOUNT_VERBOSE provides notification of autofs mounts, unmounts, and other nonessential events. This keyword is the equivalent of the -v argument for automount.
For more information, refer to the automount(1M) and the automountd(1M) man pages.
For further information, see the System Administration Guide: Network Services.