The system calls to do I/O are designed to eliminate
the differences between the various devices and styles of
There is no distinction between ``random''
and ``sequential'' I/O, nor is any logical record size imposed
The size of an ordinary file is determined
by the highest byte written on it;
no predetermination of the size of a file is necessary
To illustrate the essentials of I/O in \*sUNIX\*n, some of the basic calls are
in an anonymous language which will
indicate the required parameters without getting into the
complexities of machine language programming.
Each call to the system may potentially result in an error
return, which for simplicity is not represented
To read or write a file assumed to exist already, it must
be opened by the following call:
filep = open\|(\|name, flag\|)
\fIName\fR indicates the name of the file.
An arbitrary path name may be given.
The \fIflag\fR argument indicates whether the file is to be read, written,
or ``updated,'' that is read and written simultaneously.
It is a small integer used to identify the file
in subsequent calls to read, write
or otherwise manipulate the file.
To create a new file or completely rewrite an old one,
there is a \fIcreate\fR system call which
creates the given file if it does not exist,
or truncates it to zero length
\fICreate\fR also opens the new file for writing
and, like \fIopen,\fR returns a file descriptor.
There are no user-visible locks in the file system, nor is there any
restriction on the number of users who may have a file
open for reading or writing.
Although it is possible for the contents of a file
to become scrambled when two users write on it simultaneously,
in practice difficulties do not arise.
We take the view that locks are neither
necessary nor sufficient, in our environment,
to prevent interference between users of the same file.
They are unnecessary because we are not
faced with large, single-file data bases
maintained by independent processes.
They are insufficient because
locks in the ordinary sense, whereby
one user is prevented from writing on a file which another
when, for example, both users are editing
a file with an editor which makes
a copy of the file being edited.
It should be said that the system has
sufficient internal interlocks to maintain
the logical consistency of the file system
when two users engage simultaneously in such inconvenient
creating files in the same directory,
or deleting each other's open files.
Except as indicated below, reading and writing
This means that if a particular
byte in the file was the last byte written (or read),
the next I/O call implicitly refers to the
For each open file there is a pointer, maintained
which indicates the next byte to be read
If \fIn\fR bytes are read or written, the pointer advances
Once a file is open, the following calls
n = read\|(\|filep, buffer, count\|)
n = write\|(\|filep, buffer, count\|)
bytes are transmitted between the file specified
is the number of bytes actually transmitted.
except under exceptional conditions like I/O errors or
end of physical medium on special files;
may without error be less than
If the read pointer is so near the end of the
file that reading \fIcount\fR characters
would cause reading beyond the end, only sufficient
bytes are transmitted to reach the end of the
also, typewriter-like devices
never return more than one line of input.
When a \fIread\fR call returns with \fIn\fR equal
to zero, it indicates the end of the file.
For disk files this occurs when the read pointer
becomes equal to the current
It is possible to generate an end-of-file
from a typewriter by use of an escape
sequence which depends on the device used.
Bytes written on a file affect only those implied by
the position of the write pointer and the
count; no other part of the file
If the last byte lies beyond the end of the file, the
To do random (direct access) I/O
it is only necessary to move the read or write pointer
to the appropriate location in the file.
location = seek\|(\|filep, offset, base\|)
associated with \fIfilep\fR is moved to a position \fIoffset\fR
bytes from the beginning of the file, from the current position
of the pointer, or from the end of the file,
For some devices (e.g. paper
typewriters) seek calls are
The actual offset from the beginning of the file
to which the pointer was moved is returned
There are several additional system entries
having to do with I/O and with the file
system which will not be discussed.
get the status of a file,
change the protection mode or the owner
make a link to an existing file,
4. Implementation of the file system
As mentioned in \(sc3.2 above, a directory entry contains
only a name for the associated file and a pointer to the
This pointer is an integer called the
When the file is accessed,
its i-number is used as an index into
a system table (the \fIi-list\|\fR) stored in a known
part of the device on which
The entry thereby found (the file's
the description of the file:
3.|the physical disk or tape addresses for the file contents;
5.|time of last modification;
6.|the number of links to the file; that is, the number
of times it appears in a directory;
7.|a bit indicating whether the
8.|a bit indicating whether the file is a special file;
9.|a bit indicating whether the file is ``large'' or ``small.''
system call is to turn the path name given by the user
by searching the explicitly or implicitly named directories.
its device, i-number, and read/write pointer are stored in a system table
indexed by the file descriptor returned by the
Thus the file descriptor supplied during a subsequent
call to read or write the
may be easily related to the information necessary to access the file.
When a new file is created,
an i-node is allocated for it and a directory entry is made
which contains the name of the file and the i-node
Making a link to an existing file involves
creating a directory entry with the new name,
copying the i-number from the original file entry,
and incrementing the link-count field of the i-node.
Removing (deleting) a file is done by
link-count of the i-node specified by its directory entry
and erasing the directory entry.
If the link-count drops to 0,
any disk blocks in the file
are freed and the i-node is deallocated.
The space on all fixed or removable disks which
contain a file system is divided into a number of
blocks logically addressed from 0 up to a limit which
There is space in the i-node of each file for eight device addresses.
A \fIsmall\fR (non-special) file fits into eight or fewer
blocks; in this case the addresses of the
blocks themselves are stored.
For \fIlarge\fR (non-special) files, seven of the eight device addresses may point
to indirect blocks each containing 256 addresses
for the data blocks of the file.
the eighth word is the address of a double-indirect block containing 256 more addresses
Thus files may conceptually grow to (7+256)\v'-.3'.\v'.3'256\v'-.3'.\v'.3'512 bytes;
actually they are restricted to
(\|2\u\*t24\*n\d\|) bytes.
Once opened, a small file (size 1 to 8 blocks)
can be accessed directly.
A large file (size 9 to 32768 blocks)
requires one additional access
to read below logical block 1792
and two additional references above 1792.
The foregoing discussion applies to ordinary files.
When an I/O request is made to a file whose i-node indicates that it
the last seven device address words are immaterial,
and the first is interpreted as
a pair of bytes which constitute an internal
respectively a device type
The device type indicates which
system routine will deal with I/O on that device;
the subdevice number selects, for example, a disk drive
attached to a particular controller or one of several
similar typewriter interfaces.
In this environment, the implementation of the
system call (\(sc3.4) is quite straightforward.
maintains a system table whose
argument is the i-number and device name of the
and whose corresponding value is the
device name of the indicated special file.
This table is searched for each (i-number, device)-pair
which turns up while a path name is being scanned
the i-number is replaced by 1 (which is the i-number of the root
directory on all file systems),
and the device name is replaced by the table value.
To the user, both reading and writing of files appear to
be synchronous and unbuffered.
That is, immediately after
return from a \fIread\fR call the data are available, and conversely
after a \fIwrite\fR the user's workspace may be reused.
In fact the system maintains a rather complicated
buffering mechanism which reduces greatly the number
of I/O operations required to access a file.
Suppose a \fIwrite\fR call is made specifying transmission
U\*sNIX\*n will search its buffers to see
whether the affected disk block currently resides in core memory;
if not, it will be read in from the device.
Then the affected byte is replaced in the buffer and an
entry is made in a list of blocks to be written.
The return from the \fIwrite\fR call may then take place,
although the actual I/O may not be completed until a later time.
Conversely, if a single byte is read, the system determines
whether the secondary storage block in which the byte is located is already
in one of the system's buffers; if so, the byte can be returned immediately.
If not, the block is read into a buffer and the byte picked out.
The system recognizes when
sequential blocks of a file,
pre-reads the next block.
This significantly reduces
the running time of most programs
A program which reads or writes files in units of 512 bytes
has an advantage over a program which reads or writes
a single byte at a time, but the gain is not immense;
it comes mainly from the avoidance of system overhead.
A program which is used rarely or which does
no great volume of I/O may quite reasonably
read and write in units as small as it wishes.
The notion of the i-list is an unusual feature
In practice, this method of organizing the file system
has proved quite reliable and easy to deal with.
To the system itself, one of its strengths is
the fact that each file has a short, unambiguous name
which is related in a simple way to the protection, addressing,
and other information needed to access the file.
It also permits a quite simple and rapid
algorithm for checking the consistency of a file system,
that the portions of each device containing useful information
and those free to be allocated are disjoint and together
exhaust the space on the device.
This algorithm is independent
of the directory hierarchy, since it need only scan
the linearly-organized i-list.
At the same time the notion of the i-list induces certain
peculiarities not found in other file system organizations.
For example, there is the question of who is to be charged
for the space a file occupies,
since all directory entries for a file have equal status.
Charging the owner of a file is unfair in general,
since one user may create a file, another may link to
it, and the first user may delete the file.
The first user is still the owner of the
file, but it should be charged
The simplest reasonably fair algorithm
seems to be to spread the charges
equally among users who have links to a file.
The current version of \*sUNIX\*n avoids the
issue by not charging any fees at all.
4.1 Efficiency of the file system
To provide an indication of the overall efficiency
of \*sUNIX\*n and of the file system in particular,
timings were made of the assembly of
The assembly was run alone on the machine;
the total clock time was 32 seconds,
for a rate of 276 lines per second.
The time was divided as follows:
66% assembler execution time,
We will not attempt any interpretation of these figures
nor any comparison with other systems, but merely
generally satisfied with the overall performance