Modern network file system trace!

Okay, hot-shot network file system programmers, how do regular folks actually use their file systems? The last major study, by Daniel Ellard, et al., was in 2001 – seven years ago. Fortunately for us, Andrew Leung and colleagues from UC Santa Cruz and Netapp collected traces of several large CIFS file servers at Netapp. For a change, they traced not only the engineering file system but that of marketing, sales, and finance. They’ll be presenting at the 2008 USENIX Annual Technical Conference in Boston; here’s the sneak preview:

http://www.ssrc.ucsc.edu/Papers/leung-usenix08.pdf

(Poke, poke, Zach. :) )

3 thoughts on “Modern network file system trace!”

  1. op-lock

    The paper doesn’t mention CIFS op-lock. Op-lock removes a huge amount of traffic from the net. It is probably what is skewing the data in favor of writes.

  2. And what did those previous studies *recommend*?

    They cite an impressively long number of prior studies. But what did those studies recommend for file system users and file system implementers? It’s interesting because what I vaguely recall being common advice (read in large, sequential chunks, don’t create temporary files remotely, etc.) is quite similar to the patterns they found.

    Also, it would be useful to have the median ratio of client memory size to data transferred both for their study and prior networked file system studies, although I suspect it’s not available. That could help quantify the amount of client-side caching that avoids re-opens.

  3. Re: op-lock

    Op-locks are simply the means through which CIFS allows read and write caching. Client side caching is certainly impacting what the server sees, though I don’t think that is new to anyone.

Comments are closed.