Worked Example of Name Spaces

As a way of considering naming and access transparency let us consider user file system naming configurations that could be employed for a campus Distributed System based on the Unix file path naming convention. Chapter 10 will discuss distributed filesystems at greater length. For now, let us ignore the distribution mechanisms (as indeed we should when designing a transparent naming scheme). We make the following initial assumptions (in no significant order): Our goals include the following points: There are at least three approaches to how users see their home directories in the file system tree, and to providing some reasonable naming scheme: Probably, there will be some central machine with a number of large disks and a number of partitions on each. This machine will act as a main fileserver, storing the bulk of common data/systems, and possibly providing sink for backup and source for software distribution. [Note, many medium size systems still do not allow ;SPM_quot;striping;SPM_quot; of a file system over multiple disks The only advantage is performance of large systems - the disadvantages are many, and include consistency problems and reliability - see chapter 3]. In our example, we choose to have user filestores on ;SPM_quot;cluster servers;SPM_quot; situated in a large departments with local users predominating. Workstations will not normally have any user filestore on at all, though they may well have disks to store commonly used system files or to cache files while in use. We must accommodate autonomy within the system: There may already be existing distributed file systems in several departments with existing naming (hierarchies) strategies. So we have a set of file systems, many on the central machine, several on each cluster server. We have a set of users, who may have their home directory on the central machine or on a cluster server or a ;SPM_quot;third party;SPM_quot; server (existing department's). You can view this as the hardware tree: Somehow, we have to resolve/map/match this tree to the user's view(s). The view from any server (central or cluster) is illustrated in figure #fnfsh#268>. The terms are explained in table #tbkfsh#269>.

#figure270#
Figure: File System Naming Hierarchy

The fact that any remote mounted filestore that is not part of the actual path to a given users file store is always one level away from the ../.. path to root means that machine failures are normally hidden from users (i.e. reading the path to locate a file does not hang - so long as it is implemented by as a trace back through the tree, rather than top down on each filesystem from the root). Note that there are three levels at which a remote mount may occur: One, (the ;SPM_quot;highest;SPM_quot;), represents a departmental file store. This will allow departments to ;SPM_quot;own;SPM_quot; cluster server filestores, or include their own file servers in the scheme. One represents a project or sub organisation of a department. This allows projects in departments to act like departments. The lowest represents users being spread across more than one machine even within a departmental project. This allows groups of users to spread their home directories/ work areas over several machines (e.g. librarians who take more file space than a single machine could offer, or medical people who require more reliability than achievable from a single file server).

#figure275#
Figure: The Flat Naming Approach

In this case, we would have to employ pointers when the users file space requirements exceeded a single drive There would be a lot of symbolic links as the system grew - this may be easily managed if remote systems are only made visible (mounted) on demand, and any required links created for the duration of usage. To accommodate non-flat existing filestores, we might have pseudo-users at the same level as users on supported filestores, which are actually mount points for these whole foreign systems. (e.g./users/cs).

#figure280#
Figure: The Global Naming Approach

In all these cases, distributed access and naming is consistent with local access. However, the naming can hide the distribution or not. It is an engineering choice whether to do this.