> > If not, we can gain something by using an underlying FS > with lazy writes. > > Yes, to some extent. There's still the problem of filesystem > integrity to deal > with, and lazy writes hold up journal closure. This isn't > necessarily a > problem, except when you want to delete and launder a block > that has a write > hanging over it. It's not unsolvable, just tricky. > > Besides, what do you mean by lazy? as i see it, you have two things to guarantee: 1. attributes cached on the disk are either up to date, or clearly out of date (otherwise there's no way to tell whether cached data is stale or not), and 2. the consistency of the backing file system must be maintained. in fact, you don't need to maintain data coherency up to the very last moment, since the client is pushing data to the server for permanent storage. cached data in the local backing FS can be out of date after a client reboot without any harm whatever, so it doesn't matter a wit that the on-disk state of the backing FS trails the page cache. (of course you do need to sync up completely with the server if you intend to use CacheFS for disconnected operation, but that can be handled by "umount" rather than keeping strict data coherency all the time). it also doesn't matter if the backing FS can't keep up with the server. the failure mode can be graceful, so that as the backing FS becomes loaded, it passes more requests back to the server and caches less data and fewer requests. this is how it works when there is more data to cache than there is space to cache it; it should work the same way if the I/O rate is higher than the backing FS can handle. > Actually, probably the biggest bottleneck is the disk block allocator. in my experience with the AFS cache manager, this is exactly the problem. the ideal case is where the backing FS behaves a lot like swap -- just get the bits down onto disk in any location, without any sophisticated management of free space. the problem is keeping track of the data blocks during a client crash/reboot. the real problem arises when the cache is full and you want to cache a new file. the cache manager must choose a file to reclaim, release all the blocks for that file, then immediately reallocate them for the new file. all of this is synchronous activity. are there advantages to a log-structured file system for this purpose? is there a good way to trade disk space for the performance of your block allocator? > Well, with infinitely fast disk and network, very little - > you can afford to > be profligate on your turnover of disk space, and this > affects the options you > might choose in designing your cache. in fact, with an infinitely fast server and network, there would be no need for local caching at all. so maybe that's not such an interesting thing to consider. it might be more appropriate to design, configure, and measure CacheFS with real typical network and server latency numbers in mind. > Reading one really big file (bigger than the memory > available) over AFS, with > a cold cache it took very roughly 107% of the time it took > with no cache; but > using a warm cache, it took 14% of the time it took with no > cache. However, > this is on my particular test box, and it varies a lot from > box to box. david, what is the behavior when the file that needs to be cached is larger than the backing file system? for example, what happens when some client application starts reading a large media file that won't fit entirely in the cache?
