Plan9 files

Cold boot power off, power on your machine using your CD. You will be given the choice of installing Plan 9 or just booting a full Plan 9 system directly from the CD. Booting the system directly lets you explore the system without installing and also makes a good recovery CD. Unknown boot device: sdD0!

The digit is 0 for the master and 1 for the slave. See installation troubleshooting. You will be asked if DMA should be enabled for your ide drives, the default is 'yes', only answer 'no' if you had problems during the installation with DMA enabled.

You will be prompted for a "mouseport"; if you have a USB mouse ignore this prompt, you won't have mouse support during install, but that should be OK.

Last you will be asked for your vga settings, the default resolution is the safest option and should be enough to run the installer, you can change this later once the system is installed. Note: If you know your videocard is not supported, answer "vesa" when prompted for a monitor type. To start the installer in text mode run:.

In graphical mode the window system rio 1 will display a grey screen with some windows. The large upper window contains the install process itself. The window under it, is a running log of what has happened. A statistics graph is in the bottom corner; the graph, from top to bottom, shows system load, memory usage, interrupt rate, system call rate, context switch rate, and ethernet packet rate.

Interaction with the installation program is textual and you don't need to interact with rio during the install process. For systems with very small screens, you may find necessary to use the keyboard's arrow keys to scroll the window up and down.

When you are prompted to provide information e. When there is a small list of possible answers, they will be listed in parentheses. If there is a default choice, it will be given in square brackets and pressing enter will select this default. The installation program is structured as a sequence of tasks that must be performed; some tasks have successful completion of others as prerequisites.

At each step, you will be shown the list of completed tasks and the list of tasks that are ready to be done. Task names appear in parentheses in the text that follows. Typing at any prompt will abort the current task and return you to the main menu.

Venti 8 is an archival block storage server. You may run fossil on its own or as a write buffer backed by a Venti server. The primary value of using Venti is to store daily snapshots of your filesystem see yesterday 1.

If you want to boot Plan 9 directly or via a boot loader like LILO or the Windows boot menu, you need to allocate a primary partition. If you are content to boot from a floppy disk or from DOS via ld. The install process will scan your disk devices and give you a list of them, along with manufacturer identification strings and the disks' partitions tables.

For example:. Once you have chosen the disk, you will need to create a Plan 9 partition. To do this, the install process will run the Plan 9 fdisk program and let you partition the disk. If the disk does not already have a Plan 9 partition, fdisk will suggest one by creating but not writing a partition in the largest contiguous empty space it can find. For example, you might see:. Each line contains a partition name p1, p2, p3, and p4 are the only valid primary names; s1, etc.

Fdisk also shows the starting and ending cylinder, the size of the partition, and the type of partition. Note that partitions include the starting cylinder but not the ending cylinder. Typing h or? In this example, fdisk has created p2 in what was previously unpartitioned space.

If you agree with fdisks' proposal, you need only type w to write the changes and then q to quit fdisk. Otherwise, you can edit the table yourself, using the "a pN" and "d pN" commands to add and delete partitions. The default should be the partition you formatted in the previous step. There are four devices involved in the cw driver. The block numbers on the four devices are distinct, although the cw addresses, dump addresses, and the w addresses are highly correlated.

The cw-driver uses the w-device as the stable storage of the file system at the time of the last dump. All newly written and a large number of recently used exact copies of blocks of the w-device are kept on the c-device. The c-device is much smaller than the w-device and so the subset of w-blocks that are kept on the c-device are mapped through a hash table kept on a partition of the c-device.

The map portion of the c-device consists of blocks of buckets of entries. The declarations follow. Off waddr;. There is exactly one entry structure for each block in the data partition of the c-device. A bucket contains all of the w-addresses that have the same hash code. There are as many buckets as will fit in a block and enough blocks to have the required number of entries.

The entries in the bucket are maintained in FIFO order with an age variable and an incrementing age generator. When the age generator is about to overflow, all of the ages in the bucket are rescaled from zero.

The following steps go into converting a w-address into a c-address. The bucket is found by. After the desired bucket is found, the desired entry is found by a linear search within the bucket for the entry with the desired waddr. The state variable in the entry is one of the following.

Every w-address has a state. Blocks that are not in the c-device have the implied state Cnone. The Cread state is for blocks that have the same data as the corresponding block in the w-device. Since the c-device is much faster than the w-device, Cread blocks are kept as long as possible and used in preference to reading the w-device. Cread blocks may be discarded from the c-device when the space is needed for newer data.

The Cwrite state is when the c-device contains newer data than the corresponding block on the w-device. This happens when a Cnone , Cread , or Cwrite block is written. The Cdirty state is when the c-device contains new data and the corresponding block on the w-device has never been written. This happens when a new block has been allocated from the free space on the w-device. The Cwrite and Cdirty blocks are created and never removed. Unless something is done to convert these blocks, the c-device will gradually fill up and stop functioning.

Once a day, or by command, a dump of the cw-device is taken. The purpose of a dump is to queue the writes that have been shunted to the c-device to be written to the w-device. Since the w-device is a WORM, blocks cannot be rewritten. Blocks that have already been written to the WORM must be relocated to the unused portion of the w-device.

These are precisely the blocks with Cwrite state. The dump algorithm is as follows:. These are the blocks with state Cwrite and Cdirty. It is possible to restrict the search to within these blocks since the directory containing a modified file must have been accessed to modify the file and accessing a directory will set its modified time thus causing the block containing it to be written. The directory containing that directory must be modified for the same reason.

The tree walk is thus drastically restrained and the tree walk does not take much time. All Cdirty blocks are converted to Cdump state without relocation. At this point, all modified blocks in the cw-device have w-addresses that point to unwritten WORM blocks. These blocks are marked for later writing to the w-device with the state Cdump.

This causes the directories leading to the open files to be modified. Thus the invariant discussed in a is maintained. The dump takes a few minutes to walk the tree and mark the blocks.

It can take hours to write the marked blocks to the WORM. There is no problem if another dump is taken before the first one is finished. The newly marked blocks are just added to the marked blocks left from the first dump. If there is an error writing a marked block to the WORM then the dump state is converted to Cdump1 and manual intervention is needed. See the cwcmd mvstate command in fs 8. These blocks can be disposed of by converting their state back to Cdump so that they will be written again.

They can also be converted to Cwrite state so that they will be allocated new addresses at the next dump. In most other respects, a Cdump1 block behaves like a Cwrite block. The scp process wakes up every ten seconds and issues writes to blocks in the buffer cache that have been modified. This is done automatically on important console commands such as halt and dump.

The wcp process also wakes up every ten seconds and tries to copy a dump block from the cache to the WORM. As long as there are dump blocks to copy and there is no competition for the WORM device, the copy will continue at full speed.

Whenever there is competition for the WORM or there are no more blocks to copy, then the process will sleep ten seconds before looking again. Platter 0 is the A side of disk 0. Platter 1 is the A side of the disk 1.

Platter is the B side of disk 0. It accepts pattern-based dependency specifications that are not limited to describing rules for program construction. The result is a tool that is flexible enough to perform many maintenance tasks including database maintenance, hardware design, and document production.

This document begins by discussing the syntax of the control file, the pattern matching capabilities, and the special rules for maintaining archives. The final sections describe parallel execution and special features. The Mkfile. Mk reads a file describing relationships among files and executes commands to bring the files up to date. The specification file, called a mkfile , contains three types of statements: assignments, includes, and rules. Assignment and include statements are similar to those in C.

Rules specify dependencies between a target and its prerequisites. When the target and prerequisites are files, their modification times determine if they are out of date. Rules often contain a recipe , an rc 1 script that produces the target from the prerequisites. This simple mkfile produces an executable from a C source file:. The only rule specifies a dependence between the target file f1 and the prerequisite file f1. If the target does not exist or if the prerequisite has been modified more recently than the target, mk passes the recipe to rc for execution.

Here, f1. The native Plan 9 environment requires executables for all architectures, not only the current one. The Plan 9 version of the same mkfile looks like:. The prototype mkfile for that architecture defines architecture-specific variables: CC and LD are the names of the compiler and loader, O is the code character of the architecture. The rules compile the source file into an object file and invoke the loader to produce f1.

Invoking mk from the command line as follows. We can extend the mkfile to build two programs:. The target all , modified by the attribute V , builds both programs. The attribute identifies all as a dummy target that is not related to a file of the same name; its precise effect is explained later. This example describes cascading dependencies: the first target depends on another which depends on a third and so on. Variables and the environment. Mk does not distinguish between its internal variables and rc variables in the environment.

When mk starts, it imports each environment variable into a mk variable of the same name. Before executing a recipe, mk exports all variables, including those inherited from the environment, to the environment in which rc executes the recipe. There are several ways for a variable to take a value. It can be set with an assignment statement, inherited from the environment, or specified on the command line. Mk also maintains several special internal variables that are described in mk 1.

Assignments have the following decreasing order of precedence:. For example, a command line assignment overrides a value imported from the environment. All variable values are strings. They can be used for pattern matching and comparison but not for arithmetic.

A list is a string containing several values separated by white space. Each member is handled individually during pattern matching, target selection, and prerequisite evaluation.

A namelist is a list produced by transforming the members of an existing list. The transform applies a pattern to each member, replacing each matched string with a new string, much as in the substitute command in sam 1 or ed 1. The syntax is. When a member of the var list matches this pattern, the string C replaces A , D replaces B , and the matched string replaces itself.

Any of A , B , C , or D may be the empty string. In effect, a namelist is generated by applying the ed 1 substitute command. Namelists are useful for generating a list based on a predictable transformation.

For example,. A namelist may be used anywhere a variable is allowed except in a recipe. Command output is assigned to a variable using the normal rc syntax:. The command may be arbitrarily complex; for example,.

The include statement. The include statement replaces itself with the contents of a file. It is functionally similar to the C include statement but uses a different syntax:. The contents of the file are evaluated as they are read. An include statement may be used anywhere except in a recipe. Unlike make , mk has no built-in rules. Instead, the include statement allows generic rules to be imported from a prototype mkfile ; most Plan 9 mkfiles use this approach [Flan95].

A rule has four elements: targets, prerequisites, attributes, and a recipe. It has the form:. The first line, containing the targets, attributes, and prerequisites is the rule header ; it must begin at the left margin. The recipe contains zero or more lines, each of which begins with white space. One or more targets must be specified but the attributes, prerequisites, and recipe are optional.

Normally the target is a file that depends on one or more prerequisite files. Mk compares the modification times of each target and each prerequisite; a target is considered out of date when it does not exist or when a prerequisite has been modified more recently. When a target is out of date, mk executes the recipe to bring it up to date. When the recipe completes, the modification time of the target is checked and used in later dependency evaluations.

If the recipe does not update the target, evaluation continues with the out of date target. A prerequisite of one rule may be the target of another. When this happens, the rules cascade to define a multi-step procedure. For example, an executable target depends on prerequisite object files, each of which is a target in a rule with a C source file as the prerequisite.

Mk follows a chain of dependencies until it encounters a prerequisite that is not a target of another rule or it finds a target that is up to date. It then executes the recipes in reverse order to produce the desired target.

The rule header is evaluated when the rule is read. Variables are replaced by their values, namelists are generated, and commands are replaced by their output at this time. An attribute is usually a single letter but some are more complicated. This paper only discusses commonly used attributes; see mk 1 for a complete list. The V attribute identifies a virtual target; that is, a target that is not a file.

The target is virtual because it does not refer to a file named clean. Without the attribute, the recipe would not be executed if a file named clean existed. The Q attribute silences the printing of a recipe before execution. It is useful when the output of a recipe is similar to the recipe:. The recipe is an rc script.