| The standard UNIX command for creating a filesystem is mkfs, but Solaris also provides a simple wrapper to this called newfs that can be used to create UFS type filesystems. Before you can create a filesystem you need to create a label for the disk that includes the partition table. The new filesystem can then be created on one of these partitions. This process will normally be carried out using the Solaris format utility (discussed earlier). If we wanted to create a UFS filesystem on the partition c0t2d0s4, assuming we had defined the partition and written the label to disk we could issue the following newfs command: hydrogen# newfs /dev/dsk/c0t2d0s4 newfs: /dev/rdsk/c0t2d0s4 last mounted as /usr/local/utils newfs: construct a new file system /dev/rdsk/c0t2d0s4: (y/n)? If the partition previously had a filesystem on it, newfs will let us know where it was last mounted, just in case we have accidentally typed in the wrong device name. As an additional safeguard, if you enter "y" to proceed with the filesystem creation, newfs will respond with "/dev/dsk/c0t2d0s4 is mounted, can't mkfs" if that filesystem is currently mounted. Assuming that this is the correct partition to use and it is not currently mounted, newfs will proceed as follows: /dev/rdsk/c0t2d0s4: 206010 sectors in 126 cylinders of 15 tracks, 109 sectors 100.6MB in 8 cyl groups (16 c/g, 12.77MB/g, 6144 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 26304, 52576, 78848, 105120, 131392, 157664, 183936, hydrogen# The newfs command actually uses the UNIX mkfs command to create the filesystem. As mkfs requires a minimum selection of options and arguments, these are obtained from the partition table by newfs. You will see that the example above provides the locations of the backup superblocks. It is a good idea to make a note of these so if the main superblock becomes corrupt you know the location of an alternative one to use. Once we have created a filesystem we cannot use it straight away; it needs to be mounted first. As we saw earlier, a filesystem is mounted onto a directory that belongs to an already mounted filesystem. The directory chosen is called a "mount point" and it is sensible for this to be an empty directory, because if it contained any files or directories, they would become hidden as soon as the new filesystem was mounted. They wouldn't actually be deletedthey would still be there when the filesystem was next unmountedbut it makes more sense to use an empty directory for a mount point. So, we have just made a filesystem on the disk slice c0t2d0s4. Now we'll create a mount point and mount it so we can use it. We have decided that this filesystem is to be used to hold some scripts and utilities that will help us to look after the system. We want it under the /usr/local directory since it is customary to store locally produced files and programs here. We will create the mount point in the /usr/local directory and call it "utils": hydrogen# cd /usr/local hydrogen# mkdir utils hydrogen# mount /dev/dsk/c0t2d0s4 /usr/local/utils hydrogen# df -k Filesystem kbytes used avail capacity Mounted on /proc 0 0 0 0% /proc /dev/dsk/c0t2d0s0 48349 25654 17861 59% / /dev/dsk/c0t2d0s6 770543 557662 158943 78% /usr fd 0 0 0 0% /dev/fd /dev/dsk/c0t2d0s1 61463 5783 49534 11% /var /dev/dsk/c0t2d0s7 519718 112161 355586 24% /export/home /dev/dsk/c0t2d0s5 38539 6089 28597 18% /opt swap 133460 8 133452 1% /tmp /dev/dsk/c0t2d0s4 96716 9 87036 1% /usr/local/utils hydrogen# The df command confirms that our filesystem is now mounted on the mount point /usr/local/utils (you could also just type the mount command on its ownthere is always more than one way of doing something on a UNIX system). The mount command we used had two parameters: The first was the name of the slice of the disk that contained the filesystem; the second was the name of the directory on which we wanted to mount it. If the filesystem is of the UFS type, then mount should have no problems mounting it. But if mount could not work out what type the filesystem was, it would complain that it was not able to mount it. In this case, you can specifically tell mount what the filesystem type is by using the "-F" flag. The default filesystem type is defined in the file /etc/default/fs. hydrogen# mount -F ufs /dev/dsk/c0t2d0s4 /usr/local/utils hydrogen# If you have been trying out these commands, or examining them with a fine-tooth comb, you may have noticed that when we created the filesystem the path name of the partition (or slice) was /dev/rdsk/c0t2d0s4, but when we mounted it we used /dev/dsk/c0t2d0s4. Both paths refer to the same slice on the disk (and therefore the same filesystem); the difference is that the paths specify how that part of the disk will be accessed. If we have a look at the files with the following ls commands we see that the output line for the dsk slice begins with a "b" and the line for the rdsk slice a "c." hydrogen# ls -lL /dev/dsk/c0t2d0s4 brw-r----- 1 root sys 32, 20 Oct 19 00:47 /dev/dsk/c0t2d0s4 hydrogen# ls -lL /dev/rdsk/c0t2d0s4 crw-r----- 1 root sys 32, 20 Apr 1 18:48 /dev/rdsk/c0t2d0s4 hydrogen# The "b" stands for block and the "c" for character. If we access the disk slice using the dsk path, this means that we will be transferring data to and from the disk in block units (or multiples of blocks). If, on the other hand, we use the rdsk path, we will be communicating with the slice a character at a time (which equates to a byte at a time). This latter method tends to be called "raw input and output" (or raw I/O) and is what the "r" in rdsk stands for. When we create a filesystem the newfs (or mkfs) command creates the filesystem byte by byte so the raw device is the most appropriate. When the filesystem is mounted, accessing the data byte by byte would not be good for performance, so in this situation the block device is the correct one to use. If you create a new filesystem and you want Solaris to mount it automatically when the system boots up, or you wish to use an abbreviated form of the mount command, you should achieve this by adding an entry for it in the /etc/vfstab file (see Table 6.6). This file is scanned every time Solaris boots or the mount command is used. At boot-time all the filesystems in this file that are marked for automatic mount will be mounted. An entry in /etc/vfstab allows a filesystem to be mounted or unmounted without needing to remember the device that holds the filesystem's partition. The contents of /etc/vfstab is as follows: #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # fd - /dev/fd fd - no - /proc - /proc proc - no - /dev/dsk/c0t2d0s3 - - swap - no - /dev/dsk/c0t2d0s0 /dev/rdsk/c0t2d0s0 / ufs 1 no - /dev/dsk/c0t2d0s6 /dev/rdsk/c0t2d0s6 /usr ufs 1 no - /dev/dsk/c0t2d0s1 /dev/rdsk/c0t2d0s1 /var ufs 1 no - /dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /export/home ufs 2 yes - /dev/dsk/c0t2d0s5 /dev/rdsk/c0t2d0s5 /opt ufs 2 yes - /dev/dsk/c0t2d0s4 /dev/rdsk/c0t2d0s4 /usr/local/utils ufs 2 yes - swap - /tmp tmpfs - yes - Table 6.6. The Vfstab FileField | Description |
|---|
device to mount | This holds the full path of the device file that should be used by the mount command to mount the filesystem. This will generally be a block device under /dev, but may be a special tag for certain filesystem types (e.g., /tmp). | device to fsck | This holds the full path of the device to be used by fsck if the filesystem needs checking at boot-time. This is expected to be a block device, or a "-" if it is not appropriate to run fsck against the filesystem (e.g., /proc). | mount point | This should hold the full path of the directory upon which the filesystem is to be mounted. | FS type | This is the type of the filesystem that exists on the partition specified in the first column of the file. | fsck pass | This field is used to determine if the filesystem should be checked by fsck on boot. The field could contain any of the following: | | | • - | (do not check the filesystem) | | | • 0 | (check the filesystem for all types other than UFS) | | | • 1 | (all UFS filesystems are checked sequentially) | | | • >1 | (all UFS filesystems will be checked in parallel) | mount at boot | If this is set to "yes," the filesystem will be mounted automatically when the system boots. | mount options | If this is set, it will contain a comma-separated list of options to be supplied to the mount command when mounting this filesystem. |
Each record in /etc/vfstab must have the correct number of fields. If it is not appropriate to put in a value, then a "-" should be used. The field separator is any white space character. Solaris does not provide a command to remove a filesystem, because there is no need to have one. If you no longer need a filesystem you can just unmount it and remove its entry from /etc/vfstsb (or comment it out if you prefer). If you wish to create a new filesystem over the top of an existing one, then just use newfs or mkfs and the new one will be created over the top of the old one. If you wish to remove a filesystem so you can alter the size of its partition before recreating it in a different size, then again there is no need to remove the filesystem. Just change the size using the format utility and create the new filesystem on the partition. Checking and Repairing Filesystems Solaris provides a program for checking and repairing filesystems called fsck. It runs every time the system boots and will check any filesystem that does not have its state flag set to "clean," "stable," or "logging." The /etc/vfstab file specifies which filesystems should be checked by fsck if required. If you want to run fsck manually against a filesystem it must first be unmounted, although if you ever need to run fsck the chances are you won't be able to mount the filesystem until after you have run fsck. You should always run fsck against the raw device containing the filesystem rather than the block device (which is used for mounting the filesystem). The following example shows the checks that are performed when fsck is run on a fileystem: hydrogen# umount /usr/local/utils hydrogen# # fsck /dev/rdsk/c0t2d0s4 ** /dev/rdsk/c0t2d0s4 ** Last Mounted on /usr/local/utils ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 12 files, 13 used, 96703 free (39 frags, 12083 blocks, 0.0% fragmentation) hydrogen# mount /usr/local/utils hydrogen# In this instance, as expected, there were no problems, but if fsck does find anything wrong it will propose an action to fix the problem and will prompt you to confirm that you wish the action to be taken. If you want fsck to run noninteractively and not prompt before fixing, you can run it with the "-y" flag, but you must be aware of what the consequences are! Phase 1Check Blocks and Sizes In this phase fsck checks for bad and duplicate blocks and verifies that the size and format of each inode is correct. It also checks that the filesystem size is correct. Phase 2Check Path Names Here, fsck checks the path name of each file to make sure all the directories contained in it exist. If any bad inodes were found in phase 1, they will be removed during this phase. Phase 3Check Connectivity This phase checks the connectivity of all directories to their parents using dot and dot dot. Any unconnected directories will be placed in the lost+found directory. Phase 4Check Reference Counts Here, the number of links assigned to each file and directory is checked. Phase 5Check Cyl Groups In this phase, fsck checks the blocks in the free block list and makes sure none of them are referenced by any file. When this is complete, the number of free blocks is added to the number of allocated blocks to make sure this is equal to the number of blocks the filesystem should have. Lost+found Directories All UFS- and s5-type filesystems should also have a directory called lost+found in their root. The exception to this is that a UFS-type filesystem mounted with the "logging" option set will not need this directory. The purpose of this directory is to receive files and directories that become disconnected. When fsck checks a filesystem, it may find inodes that are valid but no directory in the filesystem makes any reference to them. There is no way that fsck can work out which directory the inode belongs to, so it will be put in lost+found. Since a directory simply holds filenames and their inode numbers, and this is the only place the filename is stored, fsck has no way of knowing what the name of the file originally was. Because of this, you will notice that if you ever do find files or directories inside a lost+found directory, they all have a number for their name. This number is actually the file's inode number. As the system administrator, it is your job to determine where files and directories in lost+found belong. If the entry is a directory with contents, then the contents should still have their original names, so this may tell you where it came from. If the entry in lost+found is a text file, then you can look at its contents, but if it is a binary file, it may be difficult to know exactly where it came from. As you become more experienced as a system administrator, you should be better able to judge where anything in lost+found originally came from. If a lost+found directory contains a large number of entries following a crash or other system event, you may find the best way to recover from the situation is to restore the whole filesystem from the most recent backup. If a UFS filesystem is mounted with the "logging" option set, then a power outage or system crash is unlikely to cause a problem that would result in files being placed in lost+found. However, it is still possible for corruption to creep into a filesystem by other methods (for example, by restoring data from a slightly corrupt backup). If the fsck program finds that you have no lost+found directory, it will create it. If it does exist, but does not have enough space allocated to it, fsck will increase its size. So you should not worry too much about your lost+found directories. Just perform regular checks for entries in them, which would be a good thing to do in a script. You could choose to regularly run the ff command as a cron job. This provides a mapping of inode number to a filename. If the output is stored, then you greatly increase the chances of reconnecting any files found in lost+found. | 
