Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ mkfs(1M) — A/UX 2.0

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

chmod(1)

fsirand(1M)

mknod(1M)

dir(4)

fs(4)

intro(7)

boot(8)

mkfs(1M)




mkfs(1M) mkfs(1M)
NAME mkfs - construct an SVFS file system SYNOPSIS /etc/mkfs device-file blocks[:inodes] [gap modulus] /etc/mkfs device-file proto [gap modulus] DESCRIPTION mkfs constructs a System V file system (SVFS) by writing on the partition (logical disk) associated with device-file ac- cording to the directions found in the remainder of the com- mand line. The command waits 10 seconds before starting to construct the file system. If the second argument is given as a string of digits (blocks), mkfs builds a file system with a single empty directory on it. The size of the file system corresponds to the value of blocks interpreted as a decimal number. This is the number of physical disk blocks the file system will occupy. The content of block 0 of the new file system is left uninitialized. If inodes is omit- ted, the default used is the value resulting when blocks is divided by 4. If the second argument is a filename that can be opened (proto), mkfs treats it as a proto file containing specifi- cations for controlling the creation of a new file system. The overall format of the proto file is as follows: program blocks inodes file-system-mode user-id group-id [ directory-name directory-mode user-id group-id [ file-name file-mode user-id group-id initial-contents ] . . . $ ] . . . (Braces surround optional items.) In the first line of the proto file format, program should be replaced with the name of a file to be copied onto block 0 of the new file system. This collection of bytes is some- times called the bootstrap program. In the second line of the proto file format, blocks should be replaced with the size of the new file system in disk (512-byte) blocks. Typically the size is the number of April, 1990 1



mkfs(1M) mkfs(1M)
blocks within a partition created with Apple(Reg.) HD SC Setup. Refer to the disk management section of A/UX Local System Administration for details about the use of Apple HD SC Setup in terms of A/UX(Reg.). Appearing after blocks in the second line is inodes. It should be replaced with the the number of inode slots for the new file system. Each inode slot can contain the operating system data that describes one file. The maximum number of configurable inode slots is 65,500, but the actual number depends on the number of blocks available to the new file system. Eight inode slots fill one disk block (512 bytes). In the third line of the proto file format is file-system- mode. The first three characters of file-system-mode are d--. The last three characters of file-system-mode are the permission digits for the owner, group, and all other users that the mount point acquires whenever the new file system is mounted on it. See mount(1M) and chmod(1) for details. Appearing after file-system-mode in the third line is user- id. It should be replaced with the numeric user ID of the user account that you wish to own the file. Appearing after user-id is group-id. It should be replaced with the numeric group ID of the group account that you wish to be associated with the file. The optional fourth line of the proto file format is the be- ginning of a directory specification. A directory specifi- cation is unusual because it requires more than one line to specify completely. At least one other line is required, and it must contain the end-directory delimiter $. Between the starting and ending lines of a directory specification, you can place any number of file specifications or addition- al (nested) directory specifications. The number of lines in a directory specification depends on the number of files and nested directories with which the file system is to be initialized. On the first line of a directory specification is directory-name, which should be replaced with a legal A/UX filename (up to 14 characters). Appearing after directory- name is directory-mode. Its replacement value can be treat- ed the same as file-system-mode. Appearing after directory-mode is user-id and group-id, which have already been described. The remaining lines of the directory specification are any number of file specifications, any number of embedded direc- tory specifications, and lastly, a line containing the end- directory delimiter $. 2 April, 1990



mkfs(1M) mkfs(1M)
The length of a file specification is one line. It begins with a value for file-name, which should be a legal A/UX filename (up to 14 characters). Appearing after filename is file-mode. It should be re- placed with a 6-character string, where the first character specifies the file type: - Specify a regular file. b Specify a block device file. c Specify a character device file. See mknod(1M) for explanations of block and character device files. The second character of file-mode specifies whether the set-user-ID permission is set or not: u Set the set-user-ID mode. - Do not set the set-user-ID mode. The third character of file-mode indicates whether the set- group-ID permission is set or not: g Set the set-group-ID mode. - Do not set the set-group-ID mode. The last three characters of file-mode are used to specify the octal number corresponding to the desired octal permis- sion digits for the owner, group, and all other users. See chmod(1). Appearing after file-mode are user-id and group-id, which have already been described. Appearing after group-id is initial-contents. It should be replaced with the pathname of the file which will be used as the source of data that is copied into file-name. If the file specification line is supposed to represent a device file, the file specification follows a slightly dif- ferent format: file-name file-mode user-id group-id major-no minor-no As can be seen, initial-contents is replaced with major and minor device numbers. See intro(7) for more information about device files, and about major and minor device numbers. Before any file specification can be given, an enclosing directory specification must be given. The format of a April, 1990 3



mkfs(1M) mkfs(1M)
directory entry is similar to a file-specification line but lacks initial-contents information. For each directory specification, mkfs makes the directory entries . and .. before continuing. Once these directory provisions are made, it can build the files for any file-specification lines that might follow up to the end-directory delimiter. Since nested directory specifications are permitted, mkfs recursively builds those nested files and directories. A sample proto file specification is: /stand/diskboot 4872 110 d--777 3 1 usr d--777 3 1 sh ---755 3 1 /bin/sh john d--755 6 1 $ b0 b--644 3 1 0 0 c0 c--644 3 1 0 0 $ $ The following directory listings illustrate the initial con- tents of the file system that would follow from the preced- ing specification: % ls -ld usr drwxr-xr-x 3 sys daemon 96 Aug 7 14:43 usr % ls -lR usr total 93 brw-r--r-- 1 sys daemon 0, 0 Aug 7 14:43 b0 crw-r--r-- 1 sys daemon 0, 0 Aug 7 14:43 c0 drwxr-xr-x 2 6 daemon 32 Aug 7 14:42 john -rwxr-xr-x 1 sys daemon 46172 Aug 7 14:42 sh usr/john: total 0 The files displayed for the usr directory are listed in re- verse of the order of their creation because the ls command sorts each line alphabetically according to filename. Whether or not a proto file is given, the rotational gap and the modulus values can be specified within the mkfs command line. The value of gap allows certain disk blocks to be treated as logically contiguous even though they are not physically contiguous. Specifically, those blocks that are gap blocks apart are treated as if they are contiguous dur- ing reads and writes. By doing this, the time delay between 4 April, 1990



mkfs(1M) mkfs(1M)
two consecutive reads or writes of blocks can be accounted for and the disk media does not rotate beyond the location of the next physical block. Rather than wait for the disk to make a complete revolution before the missed block comes under the read/write head once again, performance is better if alternating disk blocks are treated as if they were con- tiguous. The value of modulus is needed to help determine what blocks are treated as logically contiguous. With each complete re- volution, some extra offset may have to be introduced be- sides the fixed value gap. For example, for a gap value of 2 and a hypothetical 10 blocks per revolution, physical blocks 0, 2, 4, 6, and 8 would be treated as contiguous. However, if this were continued throughout the disk, odd-numbered physical blocks would never become accessible. A modulus value of 10 corrects the mapping so that after physical block 8 is mapped, block 1 is mapped, followed by 3, 5, 7, and 9. Also note that modern hard disks perform a similar function internally so that the operating system need not be encum- bered with the function of disk-block remapping. For all but a very few rare cases (hard disks not sold by Apple and of old vintage), these operating system facilities do not result in increased performance. Even when optimization is possible, it cannot be achieved unless you can determine from technical specifications for the disk what values are needed. The default values 1 for gap and 1 for modulus suppress the remapping of disk blocks. The default values are used if gap and modulus are considered illegal values or if they are om- itted. EXAMPLE To make an 800 KB file system on a 3.5-inch floppy disk, use mkfs /dev/rfloppy0 1600 This makes a file system on the floppy media referenced through /dev/rfloppy0. The new file system extends for 1600 512-byte disk blocks (800 KB). FILES /etc/fs/svfs/mkfs SEE ALSO chmod(1), fsirand(1M), mknod(1M), dir(4), fs(4), intro(7), boot(8). April, 1990 5



mkfs(1M) mkfs(1M)
BUGS When a proto file is used, mkfs can create a file system larger than the physical media. If a proto file is used, it is not possible to initialize a file larger than 64 KB, nor is there a way to specify links. 6 April, 1990

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026