Simon Wilkinson wrote:
As you note, our Linux implementation creates two copies of the data -
one in AFS's mapping, the other in the backing files. However, we cannot
easily get rid of this duplication - there's no simple mechanism of
bypassing the VM and 'writing into the chunk files directly'. Using
direct-IO would be a possibility, but we'd need to handle doing this in
the backgound, otherwise the user would end up having to wait until
chunk files actually made it to the disk, and it would limit the range
of filesystems we can use as a backing cache.
Simon,
the afs that we distribute (as part of SLC - Scientific Linux for CERN) works
with chunk files directly from the afs_linux_{read,write} entry points, namely
in order to avoid the double copy and footprint.
We only go through the VM when the file gets mmapped (nopage/readpage), which
except for 'ld' and running binaries does not happen very often.
Hence, caching still happens but on the chunk file level.
We've been running that code for some 3-4 years now, alas I never got around
to benchmarking it properly. Apart from very small buffer sizes I don't see
why avoiding another copy could slow things down, though. I was about to
submit it to openafs.org once when I discovered that I had accidentally messed
up the read-ahead. And then forgot again...
It's for 1.4, though. I'd have to look at 1.5.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
