File Identification and Allocation

newfs char−spec−file disk−name where char−spec−file Raw character special file for the corresponding disk partition disk−name The name of the entry specified in the disk description file etcdisktab HP−UX version 9 used such an approach. The main disadvantage was that required disktab entries could not include all available disk models. Simply, newer disk models appeared after the file installation cannot be included. This led to a frequent patching of the disk description table, which could be annoying. HP−UX version 10 retained the disk description file for backward compatibility but switched to the new type of the newfs command: one that is not dependent on the disk description table. 6.2.3.3 The tunefs Command UNIX also provides the command tunefs to tune adjust the created filesystem. The command can modify dynamically certain filesystem parameters. It is not unusual to realize after some time that the created filesystem does not optimally match your needs. The used filesystem cannot be easily recreated; in most cases it is almost impossible. This command is the UNIX response for that purpose. Some UNIX flavors provide other filesystem specific commands, for example, a command to extend the size of a filesystem.

6.2.4 File Identification and Allocation

Another popular term for the filesystem creation is formatting the disk or partition. In the PC world this is the only official term. In UNIX context, formatting literally means to create filesystem structures only, primarly the superblock. The created filesystem itself is absolutely empty — there is no single−user data in it. To compare with the filing closet and cabinets in the office: all drawers are now equipped with needed accessories; carriers and holders are there, as well as empty labels for easy identification of documents. These accessories take up some available space in the cabinets, but without them it would be very hard to file our papers. The UNIX counterpart for the mentioned accessories is the superblock. The superblock contains the filesystem structures system data needed for user data management. All superblock structures are free and ready for use. The superblock consumes a certain amount of the storage space to keep its system data. Keeping in mind the previous discussion, it becomes clear: Why once we reformat create a filesystem a disk or partition we lose all previously stored data. It does not mean that this data was purged. All stored data blocks remain unchanged, but the new superblock is now created. All system data in the old superblock was erased. UNIX does not know how to find this data. • 148 Let us see now in more detail how the UNIX filesystem identifies and allocates files within the corresponding storage space. It is worthwhile to mention that we are still staying within the physical filesystem layout boundaries. 6.2.4.1 Index Node inode The most important individual entity in the filesystem superblock is the inode. Inode is a shorter, more convenient, name for the index node. Each file in the filesystem is completely described by its inode. An inode includes all of the files relevant data except the file name. File names are contained in the directory where the files reside. The content of each directory includes the file names with the references to the corresponding inodes. In this way, UNIX is able to find any file by scanning the files directory until the file name matches. Afterward only the corresponding inode is used to access the file on the disk. A file can have several different names because several file names can be referenced to the same inode. They can appear in the same or different directories, but must remain in the same filesystem. These references are known as hard links see Chapter 2. An inode contains around 200 bytes, enough space to uniquely identify a file. An inode structure is presented in Figure 6.3. The type and access mode for the file The files owner user and group The time that file was last read and written and the inode was last updated The size of the file in bytes The total number of physical blocks used by the file The number of references to the file links Direct pointers for the 12 first data blocks used by the file The single indirect pointer to a single indirect block of pointers to data blocks used by the file The double indirect pointer to a double indirect block of pointers to data blocks used by the file The triple indirect pointer to a triple indirect block of pointers to data blocks used by the file Figure 6.3: The inode structure. The first part of the inode contains all information about the file. Most of the information we know from the long file listing the ls −l command. UNIX opens and reads the inode, and learns about the files type, ownership, and permissions. Based on this information, UNIX knows how to proceed with the file itself. Do not forget that UNIX processes different file types in a different way. Once we are familiar with the contents of an inode, many of the already discussed issues become clear — for example, why hard links are restrained to the same filesystem, or where the system finds information for long listing of files, or how the fsck command can check and even fix problems in the filesystem, and many others. The inode number, starting from one and increasing, identifies an inode. An identified inode must be allocated in the disk space before it can be used by the system. To allocate an inode is easy, because each inode is well defined within the superblock and the superblock is always stored in the reserved disk space well known to the system. 149 It is much tougher job to locate a file in the disk space. A file can contain an arbitrary number of data blocks, from a single block up to a huge number of blocks. These blocks could be spread over the whole disk space. Again this is the inode that precisely allocates the file itself. The second part of the inode contains a number of direct and indirect pointers to point to the location of each data block that belongs to this file. For most UNIX flavors the pointers are 32 bits long 4B, and we will assume that length in the discussion that follows. An inode can directly point to as many as 12 data blocks consumed by the file. Assuming the block size of 4 KB or 8 KB, this means a file as large as 48 KB or 96 KB is directly accessible. For larger files, indirect pointers must be used. A single indirect block contains additional pointers: a 4 KB block contains up to 1 K pointers, while a 8 KB block contains up to 2 K pointers. A double indirect block contains, or, better to say, points to, millions of new pointers. And finally a triple indirect pointer can be used in the case of extremely large files. If a file is very small, the file data is stored directly in the inode. Figure 6.4 illustrates how this allocation mechanism works. 150 Figure 6.4: File layout on a disk. A 32−bit 4 B pointer can uniquely identify one block among as many as 4 G 4 billion blocks. This is, simply, the address capability of a 32−bit pointer. More precisely, assuming a block size of 4 KB or 8 KB, the maximum size of the reachable disk space i.e., the filesystem is, respectively, 4 G × 4KB= 16 TB or 4 G × 8KB= 32 TB. Beyond that size, the block must be increased 16 KB or more during the filesystem creation. This is one of the options of the mkfs command. By the way, UNIX checks all specified options and, in the case of an inappropriate option value, cancels the command execution. However, disk blocks could be smaller than in this example, and they would still be correct — todays disk sizes are still in the range of several dozens GB. 151

6.2.5 Filesystem Performance Issues