Back to index
Extending the Operating System at the User
Level: the Ufo Global File System
Albert D. Alexandrov, Maximilian Ibel, Klaus E. Schauser, and
Chris J. Scheiman, UCSB
Generalization of JANUS to allow arbitrary user-level OS extensions, in
this case for filesystem that supports /http/... and /ftp/... paths directly.
- Trap syscalls like Janus does (using /proc) to implement global
file system. Whole file is read on open(), and subsequent calls
are redirected to the online copy . The thing that catches the
syscalls is called the Catcher.
- Raises issue: how to transparently remap file names when
args are passed
to "real" syscall. Currently, allocate space on user app's
stack and using that as arg to syscall. Correspondence between
original filename and file descriptor is maintained internally
for close, etc.
- Relies on ability for an attached (using /proc)
process to write into the attachee's address space.
- For stat and similar calls: create a sparse file "stub"
that has appropriate properties (most systems support small
sparse files with large logical extents) and redirect the syscall
to the stub. (Goal was to avoid reimplementing filesystem
calls.) But see Flaws below.
- File consistency: timeout writeback consistency, with user
selectable timeout (like NFS), plus validate-on-open.
- Performance: UFO about 20x/8x worse (Andres
benchmark/microbenchmark) for local files; of this
amount, about 7x is due to overhead of trapping syscalls.
Another technique for extending/customizing the OS, but probably more
limited since you can only modify behavior that is accessed by a
particular syscall (i.e. can't easily use it to implement policy) and
overhead is pretty high.
- stat() and getdents() hack
relies on efficient support for sparse files. On authors'
system, /tmp doesn't do this, but NFS does; but stub
creation via NFS is an order of magnitude worse, so they
are re-evaluating their decision not to rewrite stat() and
- Validate-on-open policy makes it hard to support disconnected
operation, which would be a nice extension/use of this work.
- Not clear if it's generally useful given the huge overhead for
- Maybe easier to only trap unsuccessful returns from
syscalls and examine filename to see if Ufo could have
fetched it from Internet?
- How to do syscall arg substitution cleanly if you can't write
into attached program's address space? (Overwrite in place would
be a bad hack and would fail if new filename was longer)
- Prompting for passwords for FTP really wants some underlying
authentication if stdin is not a tty. Krcp? Scp? Kftp?
Back to index