Re: Re: NFS Patch for FSCache

[David Masover <ninja@slaphack.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Howells wrote:
[...]
>>If the server is responding and delivering files faster than we can
>>write them to local disk and cull space, should we really be caching at
>>all? Is it even appropriate for the kernel to make that decision?
> 
> 
> That's a very tricky question, and it's most likely when the network + server
> retrieval speeds are better than the disk retrieval speeds, in which case you
> shouldn't be using a cache, except for the cases of where you want to be able
> to live without the server for some reason or other; and there the cache is
> being used to enhance reliability, not speed.
> 
> However, we do need to control turnover on the cache. If the rate is greater
> than we can sustain, there needs to be a way to suspend caching on certain
> files, but what the heuristic for that should be, I'm not sure.

Does the cache call sync/fsync overly often?  If not, we can gain
something by using an underlying FS with lazy writes.

I think the caching should be done asynchronously.  As stuff comes in,
it should be handed off both to the app requesting it and to a queue to
write it to the cache.  If the queue gets too full, start dropping stuff
from it the same way you do from cache -- probably LRU or LFU or
something similar.

Another question -- how much performance do we lose by caching, assuming
that both the network/server and the local disk are infinitely fast?
That is, how many cycles do we lose vs. local disk access?  Basically,
I'm looking for something that does what InterMezzo was supposed to --
make cache access almost as fast as local access, so that I can replace
all local stuff with a cache.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoplVngHNmZLgCUhAQKsLA//UJZWzkFcWUYShLvHacnS/bIDs2xOkbhJ
4wYmyb2EIpg4Qnff2zy5tlkwGt5pHCE8fDfa7ZAbFbJaaJGrmzDde3xZ9uyTCKfi
WssZXnB0uBvLmqrTrieDSsqGFtBUjfSQbF8YBcr1E9bQnOgcyATbmSjSjewpyUIb
ALYb7wxXvaNN4MwrOc0YZKlczyYlWjDDpLSn+R/rS26mXgD8o1A0tyFK5GI2TX/E
Oo6+mVpKkoqt+4jNlISxrfIBJPrHKe2Zo+HCtpLkYmw7l/Wiz301QvLUiDUMBa2m
4e1bCEn6uWhSpb+IK9Z9xDcLChvLz7fQBr7AYvepXConJhxnkn+02yuf5SYyMFDK
yn41GgeyQL2w00ybkIoAZuFgIySH5h084jebUKLjtalSslqwQBSNJfjJDOBdUAll
S7hy4VuC1F2YBCurqpj6gC8wpdiXmfEDyKozDw+js9gfNSGMN3N3kl6jCmtuss4B
eXcnQZ+3RmBTzgSB87KK5zhC/FPl/U4BEHl0o7/mtIC4GuFPpB3pZwGNK2BXbamV
Wa2jT/dbGXdkQmqUgDaQchDlo6hgnhJenuA50JoV6ea1MIpr01r7NnKHuD6+i1ep
fJO5ltT4J1XbFUsx5r0W4xzUEpblksrWxtxLB5zQmeDbMFvvAcB68KZ965E4S02N
LjM2jS/sVEc=
=OnFw
-----END PGP SIGNATURE-----