Re: On PATH_MAX

[Jonathan S. Shapiro]

On Tue, 2005-11-08 at 17:53 +0100, Michal Suchanek wrote:
> On 11/8/05, Jonathan S. Shapiro <address@hidden> wrote:

> Yes, but this also applies to the file data. Are we talking about a
> server that only allows one open file at a time? Perhaps a single-file
> server?

I think we are being unclear about what a file server is in a capability
system.

In a UNIX file system, there are three distinct functions that are
mingled together:

  1. Binding of names (i.e. directory management)
  2. Storage of file objects (i.e. byte sequences)
  3. An ad-hoc transaction processing system used to ensure that
     crashes are recoverable.

In an orthogonally persistent system, the third function is not a
responsibility of the file system at all.

In a capability system, the name binding changes as well. A directory is
a mapping whose elements are (string, cap) pairs. The string is the
object name, and the cap is the object capability. We do not (and should
not) restrict these caps to file capabilities.

So in a capability system, it is sensible to distinguish between a
directory server (a server that serves directory objects) and a file
server (a server that implements file objects, but has no responsibility
for name bindings).

In EROS, the current design implements each directory with a separate,
persistent process. Each of these processes is single-threaded. The
advantage to the single threading here is that each directory operation
is guaranteed not to interfere with any other. There is some space
overhead, but there just aren't that many directories in real systems.
Distinct directories can still operate concurrently, which is the main
benefit of multithreading for directories in any case. There is also
some traversal overhead, which may motivate a more centralized design.

Our original file system was similar: one file, one process. A given
file is single threaded. I eventually concluded that this implementation
of file had excessive space overhead for small files, so I implemented
"nfile", a server that serves multiple file objects. The nfile server is
single threaded, but you can instantiate multiple nfile servers, and
these can operate concurrently. In the rare cases where the complexity
of multithreading turns out to be justified, a separate file
implementation seems justified in any case.

One factor that helps is that EROS supports a pseudo-instruction that
enables applications to pre-probe pages into memory. This goes a long
way toward eliminating the need for multithreading.

shap