[OpenAFS] Old paper on AFS write performance

[Lester Barrows]

#include <stddisclaimer.h>

While researching methods of increasing write performance for our AFS use=
rs, I=20
ran across this paper from 1992. I'm curious if the issues highlighted st=
ill=20
apply to OpenAFS. I'm perhaps more curious about what the developers thin=
k=20
about the idea of writing chunks over the network progressively during th=
e=20
writing phase, as opposed to the file close phase.

http://www.citi.umich.edu/techreports/reports/citi-tr-92-7.pdf

Yes, this would change the file update semantics for AFS. I suppose the b=
est=20
question to ask is, as the paper mentions, does it really matter? Would t=
his=20
break anything for anyone here? Also, how difficult/possible would this b=
e to=20
implement? It strikes me that this list has perhaps the most qualified se=
t of=20
people to answer this question.

My own opinion is that partial updates might actually solve a few of the=20
non-performance related problems that I've seen people bring up here from=
=20
time to time, while decreasing the time required to flush a large file to=
 the=20
server. I'm not sure if a delay in the flush (for caching) would be a goo=
d=20
idea unless large chunks of data in the file were changing. Comments, fla=
mes,=20
been-there-done-thats?

Regards,

Lester Barrows
Asani Solutions, LLC
Code IC Systems Group
NASA Ames Research Center
Voice: 650-604-2639