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

One-line summary: Generalization of JANUS to allow arbitrary user-level OS extensions, in this case for filesystem that supports /http/... and /ftp/... paths directly.

Overview/Main Points

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.

Relevance

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.

Flaws

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 friends.
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 local filesystems.
- 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