Virtual UNIX Filesystem Logical Filesystem Layout

To start a filesystem snapshot, the mount command is used. It is fair to say this is a modified version of this command compatible with the implemented filesystem type. It is specified by the special option snapof=… that also includes a snapshot volume. The snapshot filesystem exists as long as it is mounted, and during this period its superblock controls the snapped filesystem too. By dismounting the snapshot filesystem, the snapshot process is terminated. For example, the following command creates a snapshot filesystem and mounts it into the snapdir directory: mount −F vxfs −o snapof= devvolgrfsvol devvolgrsnapvol snapdir where −F vxfs Defines the VxFS filesystem −o snapof = devvolgrfsvol Defines the mounted filesystem to be snapped devvolgrsnapvol Defines the snapshot filesystem snapdir Defines a mount−point for the snapshot filesystem other options are also possible To terminate a snapshot, simply dismount the snapshot filesystem: umount snapdir In the meantime, regular UNIX commands could be implemented on the snapshot and snapped filesystems without any restrictions. However, never forget the real nature of a snapshot filesystem — sometimes the command outputs could be very odd and confusing. For example, the df −kcommand implemented on the snapshot filesystem will show the size of the snapped filesystem. So, do not be confused when the snapshot filesystem is ten times larger than the actual size of the volume in which it was created. Simply, the df command sees the snapshot filesystem through the superblock of the snapped filesystem.

6.3.6 Virtual UNIX Filesystem

The diversity of the various UNIX filesystems and their mutual incompatibilities make their simultaneous use almost impossible. UNIX faces a challenge as to how to handle different UNIX filesystems at the same time and enables users to access their files at any time. A logical solution is to make access to files independent of their type. This would allow the users to carry out operations on a file without restrictions. It could be even extended to the not−UNIX filesystems. Such a flexible filesystem is known as virtual filesystem VFS, but full implementation remains in theory only. A needed flexibility is supposed to be achieved on the implementation of the filesystem independent vnode. The underlying mechanism of each vnode operation is, however, always dependent upon the filesystem type associated with the file being referenced by the vnode. In other words, the system must know very well how to handle the corresponding filesystem type. Thus, to perform an operation on a file, the kernel must provide mechanisms that allow the execution of a filesystem−type−dependent function to carry out an operation without knowing what that function is called or what it does. For users everything remains transparent — they can access any filesystem without knowing anything about its type. Since the kernel is independent of the filesystem type or construction, it is also flexible enough to accommodate nonUNIX filesystems such as NT, OS2, Mac, and DOS. 166 vnode does not have anything common with inode except that the names sound similar. These are two completely different concepts, with different purposes. vnode is mostly unknown to UNIX administrators and is not even mentioned in system administration books. There are at least two good reasons for that. The first reason was discussed earlier, while the second one is based on the assumption that VFS will not require any administration — everything should work well automatically. Despite that, VFS is briefly discussed here.

6.4 Disk Space Upgrade

Once a shortage of a disk space becomes evident on the system and all other possibilities have been exhausted, the only real solution is to add a new disk. Today, disks are cheap, and to make such a decision is easy. However, the full price of additional disk space includes other elements besides the disk price itself. In the past additional expenses have been mostly shadowed by the high disk price. Some elements worth consideration are: The room available for disks — internal or external • Hardware compatibility — implemented disk interface. On the UNIX platform, SCSI interface is very common, but remember that single−ended SCSI is not compatible with the differential one, or it could be a wide SCSI, or…. Also, is there a slot available on the existing SCSI controller? And so on. • The work on the disk installation and putting it into the operation • Maintenance, including backup and other long−term disk−related jobs • Each of these elements has its specific price. In most cases, this price is higher than the initial price of the disk itself. Adding a new disk is a very routine task. There is not a lot of freedom in the practical implementation, but it is good to fully understand each of the required steps. Unfortunately, almost every UNIX platform provides a different tool to implement these steps. We have already discussed some of these steps. This time we will only list them. Steps traditionally required to add a disk, independent of the UNIX platform even independent of the UNIX itself, may be summarized as: Disk formatting also known as low, or hard, formatting to establish the track layout onto the contiguous magnetic media of the disk plates • Disk partitioning to establish one or more independent storage entities within the disk for further processing • 167