Q: Why not just use a loop device on top of AFS, with the 'file:' VBD type? A: Loop devices on top of AFS files hang with large volumes of I/O -- looks like a deadlock of some sort (in my tests, a dd of around 2-300 Mb into an AFS-based loop device appears to consistently hang the kernel, even with a 500Mb or larger AFS cache). In addition, an unmodified loop.c will not fsync() the underlying file; changes won't get written back to the AFS server until loop teardown. I've added an fsync() to the worker thread of loop.c to take care of this every few seconds; that seems to work but I can't really stress test it much because of the hang problem.