generic cache in FS
Submitted by Fabien D on Wed, 03/24/2004 - 09:31.
Now, it seems that only the ext2 fs is using a cache. But later, almost all fs (I suppose) need a cache.
I think that we can use a generic cache (independently of any fs implementation). Perhaps, we can try to use the commons-cache from apache/jakarta (I don't know if it can be usefull for us).
If needed, we can have an abstract cache and concrete caches for fs implementations.
Of course, the cache could be used for write operations (delayed write) but also to anticipate future reads (If we read a block, perhaps we will ask the next block just after).
What do you think ? Does anyone thought about it ?
- Login to post comments
isn't there one`?
I think there is one that deals with FSObjects or so.
But FSObjects doesn't references (in VM) their content
I think that FSObjects (specially FSFile) aren't referencing (in VM) their own content (clusters/block).
When I said 'cache', I would like to say cache containing disk clusters (sectors) and not cache of FSObjects (file entries, directories, ...).
Perhaps, it's wrong but I don't see (except for ext2fs) such a cache.
In ext2fs (package org.jnode.fs.ext2.cache), the cache can be rendered more generic to be used by other fs.
cache
Yes, probably it should be made part of the VFS layer. As Ewout has pointed out, the ASYNC writing should be a generic solution in the VFS layer so we'll need a generic cache under that as well. (ASYNC writes are partially implemented for ext2 but turned off for now because of the problem I have mentioned in the ext2 forum (the cache was behaving strangely when used from within the FS)).
Besides, currently the disk access is handled by a driver implementing the FSBlockDeviceAPI interface. In this interface, reads and writes are defined with a byte granularity and mapped to the underlying sectors in a separate step. As ext2fs (and I think all FSs for that matter) are working with blocks as the smallest unit that is read/written I suggest to expose sector reads/writes through this interface.
1) it would be faster as only a simpler mapping is needed
2) the cache can be moved from the FS implementations to the VFS layer, but the FS will still need to address blocks (eg. explicitly tell the cache which blocks to flush if needed), so it's redundant to convert all disk operations to byte intervals and then back to sectors.
Andras
CacheListener and CacheEvent ?
What is goal of the classes CacheListener and CacheEvent ? They seems (on CVS) unused.
One cache per blockdevice
In fact, I thought of a generic cache that implements FSBlockDeviceAPI and with a reference to an underlying FSBlockDeviceAPI.
read, write and flush methods are using the cache of blocks and working with the underlying FSBlockDeviceAPI for true read/write.
We could also associate a CacheStrategy interface with our generic cache. It will allow us to change the strategy :
- no cache
- simple cache : read only what needed, write withou caching
- more complex cache : read with anticipation, delayed write, soft reference to cached block (if the VM need more memory ...)
See my proposal