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).
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).
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.
Figure:
Figure:
Figure: