Uniform resource locators (URLs)

URLs became well known, as a concept, in connection with the World Wide Web. The principle of referring to resources by a standardized name format can be adopted here too. Each operating system has a model for laying out its files in a standard pattern, but user files and local additions are usually left unspecified. Choosing a sound layout for data can make the difference between an incomprehensible chaos and a neat orderly structure. An orderly structure is useful not only for the users of the system, but also when making backups. Some of the issues are:

• Disk partitions are associated with drives or directory trees when connected to operating systems. These need names.

• Naming schemes for files and disks are operating system dependent.

• The name of a partition should reflect its function or contents.

• In a network the name of a partition ought to be a URL, i.e. contain the name of the host.

• It is good practice to consolidate file storage into a few special locations rather than spreading it out all over the network. Moreover, a basic principle in cataloging resources is:

Principle 11 (One name for one object I). Each unique resource requires a unique name, which labels it and describes its function.

with the corollary:

Corollary to principle (Aliases). Sometimes it is advantageous to use aliases or pointers to unique objects so that a generic name can point to a specific resource. The number of aliases should be kept to a minimum, to avoid confusion.

Data kept on many machines can be difficult to manage, compared with data collected on a few dedicated file-servers. Also, insecure operating systems offer files on a local disk no protection.

The URL model of file naming has several advantages. It means that one always knows the host-provider and function of a network resource. Also it falls nicely into a hierarchical directory pattern. For example, a simple but effective scheme is to use a three-level mount-point for adding disks: each user disk is mapped onto a directory with a name of the form

/site/host/content

(see figure 3.3). This scheme is adequate even for large organizations and can be extended in obvious ways. Others prefer to build up names around services, e.g.

/nfs/host/content

One objection to the naming scheme above is that the use of the server name ties a resource to a particular server host, and thus makes it difficult to move resources around. Technologies like amd (automount), AFS, DFS (the Open Group’s), and Dfs (Microsoft’s) help address this issue and can make the filesystem based on a logical layout rather than an actual physical location. On the other hand, location independence can always be secured with aliases (symbolic) or with truly distributed filesystems. Moving actual resources is always a relatively non-trivial operation, and a naming scheme like that above yields clarity for a minimum of work.

In DOS-derived operating systems one does not have the freedom to ‘mount’

network filesystems into the structure of the local disk; network disks always

/site/serverhost/content

physics

feynman schwinger tomonaga

/home /local

Figure 3.3: A universal naming scheme (URL) for network resources makes distributed data comprehensible.

become a special ‘drive’, like H: or I: etc. It is difficult to make a consistent view of the disk resources with this system, however future Windows systems will have seamless integration and one can already use filesystems like the DFS on NT which do support this model.

Within an organization a URL structure provides a global naming scheme, like those used in true network filesystems like AFS and DFS. These use the name of the host on which a resource is physically located to provide a point of reference.

This is also an excellent way of labelling backups of partitions since it is then immediately clear where the data belong. A few rules of thumb allow this naming scheme to live painlessly alongside traditional Unix naming schemes.

• When mounting a remote filesystem on a host, the client and server direc-tories should always have exactly the same name, to avoid confusion and problems later [221].

• The name of every filesystem mount-point should be unique and tell us something meaningful about where it is located and what its function is.

• For tradition, one can invoke the corollary and use an alias to provide a generic reference point for specific resources. For instance, names like /usr/localcan be used to point to more accurate designations like/site/

host/local. On different clients, the alias /usr/local might point to a filesystem on a single server, or to filesystems on many servers. The purpose of an alias is to hide this detail, while the purpose of the filesystem designation is to identify it. This satisfies all needs and is consistent.

• It doesn’t matter whether software compiles the path names of special direc-tories into software as long as we follow the points above.

For example, the following scheme was introduced at Oslo at the University and later copied at the College. The first link in the mount-point is the department of the organization or, in our case, the university faculty which the host belongs to;

the second link is the name of the host to which the disk is physically connected, and the third and final link is a name which reflects the contents of the partition.

Some examples:

/site/hostname/content /research/grumpy/local /research/happy/home1 /research/happy/home2 /sales/slimy/home1 /physics/einstein/data /biology/pauling/genome-db

The point of introducing this scheme was two-fold:

• To instantly be able to identify the server on which the disk resource physi-cally resided.

• To instantly be able to identify the correct locations of files on backup tapes, without any special labelling of the tapes (see section 12.3.3).

System administrators are well known for strong opinions, and many practicing system administrators will strongly disagree with this practice. However, one should have an excellent reason to ignore a systematic approach.