-----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-----
