Single-device mountpoints

Consider an example involving three servers:

Server A

A QNX 4 filesystem. Its mountpoint is /. It contains the files bin/true and bin/false.

Server B

A flash filesystem. Its mountpoint is /bin. It contains the files ls and echo.

Server C

A single device that generates numbers. Its mountpoint is /dev/random.

At this point, the process manager's internal mount table would look like this:

Of course, each "Server" name is actually an abbreviation for the nd,pid,chid for that particular server channel.

Now suppose a client wants to send a message to Server C. The client's code might look like this:

int fd;
fd = open("/dev/random", ...);
read(fd, ...);
close(fd);

In this case, the C library will ask the process manager for the servers that could potentially handle the path /dev/random. The process manager would return a list of servers:

• Server C (most likely; longest path match)
• Server A (least likely; shortest path match)

From this information, the library will then contact each server in turn and send it an open message, including the component of the path that the server should validate:

1. Server C receives a null path, since the request came in on the same path as the mountpoint.
2. Server A receives the path dev/random, since its mountpoint was /.

As soon as one server positively acknowledges the request, the library won't contact the remaining servers. This means Server A is contacted only if Server C denies the request.

This process is fairly straightforward with single device entries, where the first server is generally the server that will handle the request. Where it becomes interesting is in the case of unioned filesystem mountpoints.