In message <[EMAIL PROTECTED]>, Thomas Pornin writes:
[...]
> To answer to the second question, I need the experience from the
> filesystem-guys, who know how a filesystem is typically used, and
> who are supposed to at least lurk in this mailing-list. Hence this
> discussion.
> It is my understanding that typical filesystem write usage is either
> creating new files and filling them, truncating files to zero length and
> filling them, and appending to files. For these operations, the checksum
> cost is zero (in terms of disk accesses). This is not true for mmaped()
> files (databases, production of executables...) but I think (and I beg
> for comments) that this may be handled with a per-file exception (for
> instance, producing the executable file in /tmp and then copying it
> into place -- since /tmp may be emptied at boottime, it is pointless to
> ensure data integrity in /tmp when the machine is not powered).
> 
> 
> Any comment is welcome, of course. I thank you for sharing part of your
> time reading my prose.
> 
> 
>       --Thomas Pornin

Thomas, f/s usage patterns vary of course.  There are at least three papers
you should take a look at concerning this topic:

L. Mummert and M. Satyanarayanan. 
Long Term Distributed File Reference Tracing: Implementation and Experience. 
Technical Report CMU-CS-94-213. 
Carnegie Mellon University, Pittsburgh, U.S., 1994. 

Werner Vogels
File system usage in Windows NT 4.0
SOSP '99

D. Roselli, J. R. Lorch, and T. E. Anderson. 
A Comparison of File System Workloads. 
To appear in USENIX Conf. Proc., June 2000.
(You're going to have to wait to read that one, unless you can get an
advance copy from the authors.  It's an interesting paper.)

Also, I've had to visit this issue recently when I added size-changing
support to my stackable templates (for compression, CBC encryption, all
kinds of encoding, etc.)  You can get a copy of a paper (entitled
"Performance of Size-Changing Algorithms in Stackable File Systems") in
http://www.cs.columbia.edu/~ezk/research/fist/.

Cheers,
Erez.

Reply via email to