[cap-talk] Capability-based Projects - theory vs. practice

[Jonathan S. Shapiro]

>In the same situation with Keykos the integrity of your application 
>depends only
>on the way you use the file system. I can corrupt only my own files.

Thbis is fundamentally a complexity argument. An FS built on a persistent substrate and absolved of directory (name binding) management is MUCH simpler than its Mach counterpart. The storage overhead of the KeyKos approach is, on average, greater than 250% of average file size. That seemed wasteful to me, and of course nothing prevents instantiating one FS per user in EROS, or even per file, with no substantially greater overhead than KeyKos, but incurred only where warranted.

Charlie writes:

>If I'm not mistaken, in EROS (to the extent it had a file system)
> there was a single process serving all files. I believe this was done
>for performance reasons - traversing directory paths can be done
>without context switches.

This is incorrect. The "nfile" server served multiple files, but not directories. No intrinsic rstio of nfile instances to file instances was assumed.

The directory traversal overhead issue is serious, hbowever. One process per directory is flatly prohibitive on both space and performance grounds.

shap