System Administration Guide, Volume 1

Chapter 34 Managing File Systems (Overview)

This is a list of the overview information in this chapter.

What's New in File Systems?

This section describes new file system features.

The /var/run File System

A new TMPFS-mounted file system, /var/run, is the repository for temporary system files that are not needed across system reboots in this Solaris release and future releases. The /tmp directory continues to be repository for non-system temporary files.

Because /var/run is mounted as a memory-based file system rather than a disk-based file system, updates to this directory do not cause unnecessary disk traffic that would interfere with systems running power management software.

The /var/run directory requires no administration. You may notice that it is not unmounted with the umount -a or the umountall command.

For security reasons, /var/run is owned by root.

Mount Table Changes (/etc/mnttab)

In previous Solaris releases, /etc/mnttab was a text-based file that stored information about mounted file systems. The downside of being a file was that it could get out of sync with the actual state of mounted file systems.

Now the /etc/mnttab file is a MNTFS file system that provides read-only information directly from the kernel about mounted file systems for the local system.

Note the following mnttab behavior changes:

No administration is required for the /etc/mnttab mount table.

See mnttab(4) for more information.

Using the Universal Disk Format (UDF) File System

The UDF file system, the industry-standard format for storing information on the optical media technology called DVD (Digital Versatile Disc or Digital Video Disc), is included in this Solaris release.

The UDF file system is provided as dynamically loadable, 32-bit and 64-bit modules, with system administration utilities for creating, mounting, and checking the file system on both SPARC and IA platforms. The Solaris UDF file system works with supported ATAPI and SCSI DVD drives, CD-ROM devices, and disk and diskette drives. In addition, the Solaris UDF file system is fully compliant with the UDF 1.50 specification.

The UDF file system support is provided in the following new packages:

UDF Features and Benefits

In this Solaris release, the UDF file system provides the following features:

The following features are not included in this UDF file system release:

Hardware and Software Requirements

The UDF file system requires the following:

UDF Compatibility Issues

This first Solaris UDF file system implementation provides:

How to Connect a DVD-ROM Device

  1. Become superuser.

  2. Create the /reconfigure file.

    # touch /reconfigure
  3. Shut down the system and turn off power.

    # init 0
  4. Connect the DVD-ROM device.

  5. Turn on power to the system.

How to Access Files on a DVD-ROM Device

  1. Verify the DVD-ROM device is automatically mounted.

    $ ls /cdrom

    Note -

    If the system has both a CD-ROM and DVD-ROM device, the CD-ROM might be named /cdrom/cdrom0 and the DVD-ROM might be named /cdrom/cdrom1. If the system only has a DVD-ROM device, then try using /cdrom/cdrom0.

  2. Display content with ls command.

    $ ls /cdrom/cdrom1
    Copyright 	filea		fileb

    Automatic display with the CDE file manager is not implemented yet. All other CDE file manager functions--drag and drop for copying and imagetool features--are available.

How to Display UDF File System Parameters

Display UDF file system parameters by using the mkfs command.

  1. Become superuser.

  2. Display UDF file system parameters.

    # mkfs -F udfs -m /dev/rdsk/device-name

How to Create a UDF File System

Create a UDF file system by using the mkfs command.

  1. Become superuser.

  2. Create a UDF file system.

    # mkfs -F udfs /dev/rdsk/device-name
  3. Verify the UDF file system is created by mounting it. See "How to Mount a UDF File System" for more information.

See mkfs_udfs(1M) for more information.

How to Identify the UDF File System Type

Identify the UDF file system type by using the fstyp command.

  1. Become superuser.

  2. Determine whether a file system is a UDF file system.

    # fstyp -v /rdev/dsk/device-name

How to Check a UDF File System

Check the integrity of a UDF file system by using the fsck command.

  1. Become superuser.

  2. Check a UDF file system.

    # fsck -F udfs /dev/rdsk/device-name

See fsck_udfs(1M) for more information.

How to Mount a UDF File System

Mount a UDF file system.

  1. Become superuser.

  2. Mount a UDF file system.

    # mount -F udfs /dev/dsk/device-name /mount-point
  3. Verify the UDF file system is mounted.

    # ls /mount-point

See mount_udfs(1M) for more information.

How to Unmount a UDF File System

Unmount a UDF file system.

  1. Become superuser.

  2. Unmount a UDF file system.

    # umount /dev/dsk/device-name 

How to Label a Device with a UDF File System and Volume Name

Create a file system and volume name for a UDF file system.

  1. Become superuser.

  2. Create a file system and volume name for the UDF file system.

    # labelit -F UDFS /dev/rdsk/device-name fsname volume

See labelit_udfs(1M) for more information.

Overview of File Systems

A file system is a structure of directories used to organize and store files. The term file system is used to describe:

Usually, you can tell from context which meaning is intended.

The Solaris operating environment uses the virtual file system (VFS) architecture, which provides a standard interface for different file system types. The VFS architecture enables the kernel to handle basic operations, such as reading, writing, and listing files; and makes it easier to add new file systems.

Administering file systems is one of your most important system administration tasks. Read this chapter for file system background and planning information. Refer to other chapters in the System Administration Guide for instructions about the following tasks:

For This Task ... 

See ... 

Creating new file systems 

Chapter 35, Creating File Systems (Tasks) and Chapter 37, The Cache File System (Tasks)

Making local and remote files available to users 

Chapter 36, Mounting and Unmounting File Systems (Tasks)

Connecting and configuring new disk devices 

Chapter 28, Disk Management (Overview)

Designing and implementing a backup schedule and restoring files and file systems as needed 

Chapter 42, Backing Up and Restoring File Systems (Overview)

Checking for and correcting file system damage 

Chapter 39, Checking File System Integrity

Types of File Systems

The Solaris operating environment supports three types of file systems:

To identify the type for a particular file system, see "Determining a File System's Type".

Disk-Based File Systems

Disk-based file systems are stored on physical media such as hard disks, CD-ROMs, and diskettes. Disk-based file systems can be written in different formats. The available formats are:

Disk-Based File System  

Format Description 


UNIX file system (based on the BSD Fast File system that was provided in the 4.3 Tahoe release). UFS is the default disk-based file system for the Solaris operating environment.

Before you can create a UFS file system on a disk, the disk must be formatted and divided into slices. See Chapter 28, Disk Management (Overview) for complete information on formatting disks and dividing disks into slices.


High Sierra, Rock Ridge, and ISO 9660 file system. High Sierra is the first CD-ROM file system; ISO 9660 is the official standard version of the High Sierra File System. The HSFS file system is used on CD-ROMs, and is a read-only file system. Solaris HSFS supports Rock Ridge extensions to ISO 9660, which, when present on a CD-ROM, provide all UFS file system features and file types except for writability and hard links.


PC file system, which allows read/write access to data and programs on DOS-formatted disks written for DOS-based personal computers.


The UDF file system, the industry-standard format for storing information on the optical media technology called DVD (Digital Versatile Disc or Digital Video Disc).  

Each type of disk-based file system is customarily associated with a particular media device:

These associations are not, however, restrictive. For example, CD-ROMs and diskettes can have UFS file systems created on them.

Network-Based File Systems

Network-based file systems can be accessed over the network. Typically, network-based file systems reside on one system, typically a server, and are accessed by other systems across the network. NFSTM is the only available network-based or distributed computing file system.

With NFS, you can administer distributed resources (files or directories) by exporting them from a server and mounting them on individual clients. See "The NFS Environment" for more information.

Virtual File Systems

Virtual file systems are memory-based file systems that provide access to special kernel information and facilities. Most virtual file systems do not use file system disk space. However, the Cache File System (CacheFS) uses a file system on the disk to contain the cache, and some virtual file systems, such as the Temporary File System (TMPFS), use the swap space on a disk.

The Cache File System

The Cache File System (CacheFSTM) can be used to improve performance of remote file systems or slow devices such as CD-ROM drives. When a file system is cached, the data read from the remote file system or CD-ROM is stored in a cache on the local system. See Chapter 37, The Cache File System (Tasks) for detailed information on setting up and administering CacheFS File Systems.

The Temporary File System

The Temporary File System (TMPFS) uses local memory for file system reads and writes, which is typically much faster than a UFS file system. Using TMPFS can improve system performance by saving the cost of reading and writing temporary files to a local disk or across the network. For example, temporary files are created when you compile a program, and the operating system generates a lot of disk or network activity while manipulating these files. Using TMPFS to hold these temporary files can significantly speed up their creation, manipulation, and deletion.

Files in TMPFS file systems are not permanent. They are deleted when the file system is unmounted and when the system is shut down or rebooted.

TMPFS is the default file system type for the /tmp directory in the Solaris operating environment. You can copy or move files into or out of the /tmp directory, just as you would in a UFS file system.

The TMPFS file system uses swap space as a temporary backing store. If a system with a TMPFS file system does not have adequate swap space, two problems can occur:

See Chapter 35, Creating File Systems (Tasks) for information about creating TMPFS file systems. See Chapter 38, Configuring Additional Swap Space (Tasks) for information about increasing swap space.

The Loopback File System

The Loopback File System (LOFS) lets you create a new virtual file system, so you can access files by using an alternative path name. For example, you can create a loopback mount of root (/) on /tmp/newroot, which will make the entire file system hierarchy look like it is duplicated under /tmp/newroot, including any file systems mounted from NFS servers. All files will be accessible either with a path name starting from root (/), or with a path name starting from /tmp/newroot.

See Chapter 35, Creating File Systems (Tasks) for information on how to create LOFS file systems.

The Process File System

The Process File System (PROCFS) resides in memory. It contains a list of active processes, by process number, in the /proc directory. Information in the /proc directory is used by commands like ps. Debuggers and other development tools can also access the address space of the processes by using file system calls.

Caution - Caution -

Do not delete the files in the /proc directory. Deleting processes from the /proc directory will not kill them. Remember, /proc files do not use disk space, so there is little reason to delete files from this directory.

The /proc directory does not require system administration.

Additional Virtual File Systems

These additional types of virtual file systems are listed for your information. They do not require administration.

Virtual File System 


FIFOFS (first-in first-out) 

Named pipe files that give processes common access to data

FDFS (file descriptors) 

Provides explicit names for opening files using file descriptors


Used mostly by STREAMS for dynamic mounts of file descriptors on top of files

SPECFS (special) 

Provides access to character special and block devices


File system used by the kernel for swapping

File System Administration Commands

Most file system administration commands have both a generic and a file system-specific component. You should use the generic commands whenever possible, which call the file system-specific component. The table below lists the generic file system administrative commands, which are located in the /usr/sbin directory.

Table 34-1 Generic File System Administrative Commands




Clears inodes 


Reports the number of free disk blocks and files 


Lists file names and statistics for a file system 


Checks the integrity of a file system and repairs any damage found 


Debugs the file system 


Determines the file system type 


Lists or provides labels for file systems when copied to tape (for use by the volcopy command only)


Makes a new file system 


Mounts local and remote file systems 


Mounts all file systems specified in the virtual file system table (/etc/vfstab)


Generates a list of path names with their i-numbers 


Unmounts local and remote file systems 


Unmounts all file systems specified in a virtual file system table (/etc/vfstab)


Makes an image copy of a file system 

How the File System Commands Determine the File System Type

The generic file system commands determine the file system type by following this sequence:

  1. From the -F option, if supplied.

  2. By matching a special device with an entry in /etc/vfstab file (if special is supplied). For example, fsck first looks for a match against the fsck device field; if no match is found, it then checks the special device field.

  3. By using the default specified in /etc/default/fs for local file systems and in /etc/dfs/fstypes for remote file systems.

Manual Pages for Generic and Specific Commands

Both the generic and specific commands have manual pages in the man Pages(1M): System Administration Commands. The specific manual page is a continuation of the generic manual page. To look at a specific manual page, append an underscore and the file system type abbreviation to the generic command name. For example, to see the specific manual page for mounting a UFS file system, type man mount_ufs.

The Default Solaris File Systems

The Solaris file system is hierarchical, starting with the root directory (/) and continuing downwards through a number of directories. The Solaris installation process enables you to install a default set of directories and uses a set of conventions to group similar types of files together. The table below provides a summary of the default Solaris file systems, and shows the type of each file system.

The root (/) and /usr file systems are both needed to run a system. Some of the most basic commands from the /usr file system (like mount) are included in the root (/) file system so that they are available when the system boots or is in single-user mode and /usr is not mounted. See Chapter 40, UFS File System Reference for more detailed information on the default directories for the root (/) and /usr file systems.

Table 34-2 The Default Solaris File Systems

File System or Directory 

File System Type 


root (/)


The top of the hierarchical file tree. The root directory contains the directories and files critical for system operation, such as the kernel, the device drivers, and the programs used to boot the system. It also contains the mount point directories where local and remote file systems can be attached to the file tree. 



System files and directories that can be shared with other users. Files that run only on certain types of systems are in the /usr directory (for example, SPARC executables). Files (such as man pages) that can be used on all types of systems are in /usr/share.

/export/home or /home


The mount point for users' home directories, which store users work files. By default /home is an automounted file system. On standalone systems, /home might be a UFS file system on a local disk slice.



System files and directories that are likely to change or grow over the life of the local system. These include system logs, vi and ex backup files, and uucp files.



Mount point for optional, third-party software. On some systems, /opt might be a UFS file system on a local disk slice.



Temporary files, cleared each time the system is booted or the /tmp file system is unmounted.



A list of active processes, by number. 

Swap Space

The Solaris operating environment uses some disk slices for temporary storage rather than for file systems. These slices are called swap slices, or swap space. Swap space is used as virtual memory storage areas when the system does not have enough physical memory to handle current processes.

Since many applications rely on swap space, it is important to know how to plan for, monitor, and add more swap space when needed. For an overview about swap space and instructions for adding swap space, see Chapter 38, Configuring Additional Swap Space (Tasks).

The UFS File System

UFS is the default disk-based file system in Solaris operating environment. Most of the time, when you administer a disk-based file system, you will be administering UFS file systems. UFS provides the following features:

UFS Feature 


State flags 

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

Extended fundamental types (EFT) 

32-bit user ID (UID), group ID (GID), and device numbers.

Large file systems 

A UFS file system can be as large as 1 Tbyte (terabyte). The Solaris operating environment does not provide striping, which is required to make a logical slice large enough for a 1-Tbyte file system. However, the SolsticeTM DiskSuiteTM software, available from Sun, provides this capability.

Large files 

By default, a UFS file system can have regular files larger than 2 Gbytes (gigabytes). You must explicitly use the nolargefiles mount option to enforce a 2 Gbyte maximum file size limit. This limit was removed in the Solaris 2.6 release.

See Chapter 40, UFS File System Reference for detailed information about the UFS file system.

Parts of a UFS File System

When you create a UFS file system, the disk slice is divided into cylinder groups, which are made up of one or more consecutive disk cylinders. The cylinder groups are then further divided into addressable blocks to control and organize the structure of the files within the cylinder group. Each type of block has a specific function in the file system. See "The Structure of UFS File System Cylinder Groups" for more detailed information about each type of block.

If you want to customize a file system using arguments with the newfs command or the mkfs command, see Chapter 40, UFS File System Reference for information about altering these parameters.

UFS Logging

UFS logging is the process of storing transactions (changes that make up a complete UFS operation) in a log before the transactions are applied to the UFS file system. Once a transaction is stored, the transaction can be applied to the file system later.

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 is true even when a system crashes, which normally interrupts system calls and introduces inconsistencies into a UFS file system.

UFS logging provides two advantages. It prevents file systems from becoming inconsistent, therefore eliminating the need to run fsck. And, because fsck can be bypassed, UFS logging reduces the time required to reboot a system if it crashes, or after an unclean halt (see "What fsck Checks and Tries to Repair" for details on unclean halts). UFS logging can significantly reduce the boot time on systems that have large file systems, which usually take a long time to read and verify with fsck.

The log created by UFS logging is continually flushed as it fills up. The log is totally flushed when the file system is unmounted or as a result of the lockfs -f command.

UFS logging is not enabled by default. To enable UFS logging, you must specify the -o logging option with the mount command in the /etc/vfstab file or when mounting the file system. The log is allocated from free blocks on the file system, and it is sized approximately 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes. Logging can be enabled on any UFS, including the root (/) file system. Also, the fsdb command has been updated with new debugging commands to support UFS logging.

Planning UFS File Systems

When laying out file systems, you need to consider possible conflicting demands. Here are some suggestions:

See Chapter 35, Creating File Systems (Tasks) for information on default file system parameters as well as procedures for creating new UFS file systems.

Mounting and Unmounting File Systems

Before you can access the files on a file system, you need to mount the file system. Mounting a file system attaches that file system to a directory (mount point) and makes it available to the system. The root (/) file system is always mounted. Any other file system can be connected or disconnected from the root (/) file system.

When you mount a file system, any files or directories in the underlying mount point directory are unavailable as long as the file system is mounted. These files are not permanently affected by the mounting process, and they become available again when the file system is unmounted. However, mount directories are typically empty, because you usually do not want to obscure existing files.

For example, the figure below shows a local file system, starting with a root (/) file system and subdirectories sbin, etc, and opt.

Figure 34-1 Sample root (/) File System


Now, say you wanted to access a local file system from the /opt file system that contains a set of unbundled products.

First, you must create a directory to use as a mount point for the file system you want to mount, for example, /opt/unbundled. Once the mount point is created, you can mount the file system (by using the mount command), which makes all of the files and directories in /opt/unbundled available, as shown in the figure below. See Chapter 36, Mounting and Unmounting File Systems (Tasks) for detailed instructions on how to perform these tasks.

Figure 34-2 Mounting a File System


The Mounted File System Table

Whenever you mount or unmount a file system, the /etc/mnttab (mount table) file is modified with the list of currently mounted file systems. You can display the contents of this file with the cat or more commands, but you cannot edit it. Here is an example of an /etc/mnttab file:

$ more /etc/mnttab
/dev/dsk/c0t0d0s0  /  ufs rw,intr,largefiles,onerror=panic,suid,dev=2200000 938557523
/proc   /proc   proc    dev=3180000     938557522
fd      /dev/fd fd      rw,suid,dev=3240000     938557524
mnttab  /etc/mnttab     mntfs   dev=3340000     938557526
swap    /var/run        tmpfs   dev=1   938557526
swap    /tmp    tmpfs   dev=2   938557529
/dev/dsk/c0t0d0s7 /export/home ufs rw,intr,largefiles,onerror=panic,suid,dev=2200007 938557529

The Virtual File System Table

It would be a very time-consuming and error-prone task to manually mount file systems every time you wanted to access them. To fix this, the virtual file system table (the /etc/vstab file) was created to maintain a list of file systems and how to mount them. The /etc/vfstab file provides two important features: you can specify file systems to automatically mount when the system boots, and you can mount file systems by using only the mount point name, because the /etc/vfstab file contains the mapping between the mount point and the actual device slice name.

A default /etc/vfstab file is created when you install a system depending on the selections you make when installing system software; however, you can edit the /etc/vfstab file on a system whenever you want. To add an entry, the main information you need to specify is the device where the file system resides, the name of the mount point, the type of the file system, whether you want it to mount automatically when the system boots (by using the mountall command), and any mount options.

The following is an example of an /etc/vfstab file. Comment lines begin with #. This example shows an /etc/vfstab file for a system with two disks (c0t0d0 and c0t3d0).

$ more /etc/vfstab
#device         device          mount           FS      fsck   mount  mount
#to mount       to fsck         point           type    pass   at boot options
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 /          ufs     1       no      -
/proc           -               /proc           proc    -       no      -
/dev/dsk/c0t0d0s1 -                -            swap    -       no      -
swap            -               /tmp            tmpfs   -       yes     -
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr       ufs     2       no      -
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /test      ufs     2       yes     -

In the above example, the last entry specifies that a UFS file system on the /dev/dsk/c0t3d0s7 slice will be automatically mounted on the /test mount point when the system boots. Note that, for root (/) and /usr, the mount at boot field value is specified as no, because these file systems are mounted by the kernel as part of the boot sequence before the mountall command is run.

See Chapter 36, Mounting and Unmounting File Systems (Tasks) for descriptions of each of the /etc/vfstab fields and information on how to edit and use the file.

The NFS Environment

NFS is a distributed file system service that can be used to share resources (files or directories) from one system, typically a server, with other systems across the network. For example, you might want to share third-party applications or source files with users on other systems.

NFS makes the actual physical location of the resource irrelevant to the user. Instead of placing copies of commonly used files on every system, NFS allows you to place one copy on one system's disk and let all other systems access it across the network. Under NFS, remote files are virtually indistinguishable from local ones.

A system becomes an NFS server if it has resources to share over the network. A server keeps a list of currently shared resources and their access restrictions (such as read/write or read-only).

When you share a resource, you make it available for mounting by remote systems.

You can share a resource in these ways:

See Chapter 36, Mounting and Unmounting File Systems (Tasks) for information on how to share resources. See System Administration Guide, Volume 3 for a complete description of NFS.


You can mount NFS file system resources by using a client-side service called automounting (or AutoFS), which enables a system to automatically mount and unmount NFS resources whenever you access them. The resource remains mounted as long as you remain in the directory and are using a file. If the resource is not accessed for a certain period of time, it is automatically unmounted.

AutoFS provides the following features:

The AutoFS service is initialized by automount, which is run automatically when a system is booted. The automount daemon, automountd, runs continuously and is responsible for the mounting and unmounting of the NFS file systems on an as-needed basis. By default, the Solaris operating environment automounts /home.

AutoFS works with file systems specified in the name service. This information can be maintained in NIS, NIS+, or local /etc files. With AutoFS, you can specify multiple servers to provide the same file system. This way, if one of the servers is down, AutoFS can try to mount from another machine. You can specify which servers are preferred for each resource in the maps by assigning each server a weighting factor.

See System Administration Guide, Volume 3 for complete information on how to set up and administer AutoFS.

The Cache File System (CacheFS)

If you want to improve the performance and scalability of an NFS or CD-ROM file system, you should use the Cache File System (CacheFS). CacheFS is a general purpose file system caching mechanism that improves NFS server performance and scalability by reducing server and network load.

Designed as a layered file system, CacheFS provides the ability to cache one file system on another. In an NFS environment, CacheFS increases the client per server ratio, reduces server and network loads, and improves performance for clients on slow links, such as Point-to-Point Protocol (PPP). You can also combine CacheFS with the AutoFS service to help boost performance and scalability.

See Chapter 37, The Cache File System (Tasks) for detailed information about CacheFS.

Deciding How to Mount File Systems

The table below provides guidelines on mounting file systems based on how you use them.

Table 34-3 Determining How to Mount File Systems

If You Need to Mount ... 

Then You Should Use ... 

Local or remote file systems infrequently 

The mount command entered manually from the command line.

Local file systems frequently 

The /etc/vfstab file, which will mount the file system automatically when the system is booted in multi-user state.

Remote file systems frequently, such as home directories 

  • The /etc/vfstab file, which will automatically mount the file system when the system is booted in multi-user state.

  • AutoFS, which will automatically mount or unmount the file system when you change into (mount) or out of (unmount) the directory.

To enhance performance, you can also cache the remote file systems by using CacheFS. 

You can mount a CD-ROM containing a file system by simply inserting it into the drive (Volume Management will automatically mount it). You can mount a diskette containing a file system by inserting it into the drive and running the volcheck command. See Chapter 14, Guidelines for Using CDs and Diskettes (Overview) for more information.

Determining a File System's Type

You can determine a file system's type by using the following:

How to Determine a File System's Type

This procedure works whether the file system is mounted or not.

Determine a file system's type by using the grep command.

$ grep mount-point fs-table


Specifies the mount point name of the file system for which you want to know the type. For example, the /var directory.


Specifies the absolute path to the file system table in which to search for the file system's type. If the file system is mounted, fs-table should be /etc/mnttab. If it isn't mounted, fs-table should be /etc/vfstab.

Information for the mount point is displayed.

Note -

If you have the raw device name of a disk slice, you can use the fstyp(1M) command to determine a file system's type (if the disk slice contains a file system).

Example--Determining a File System's Type

The following example uses the /etc/vfstab to determine the type of the /export file system.

$ grep /export /etc/vfstab
/dev/dsk/c0t3d0s6   /dev/rdsk/c0t3d0s6  /export ufs   2       yes    -

The following example uses the /etc/mnttab file to determine the file system type of the currently mounted diskette (mounted by volume management).

$ grep /floppy /etc/mnttab
/vol/dev/diskette0/unnamed_floppy   /floppy/unnamed_floppy  pcfs rw,nohidden,
nofoldcase,dev=16c0009      89103376