Messages in this thread | | | Date | Fri, 08 Jun 2001 13:15:13 +0800 | From | Michael Clark <> | Subject | Re: CacheFS |
| |
"Albert D. Cahalan" wrote: > > Jan Kasprzak writes: > > > Another goal is to use the Linux filesystem > > as a backing store (as opposed to the block device or single large file > > used by CODA). > ... > > - kernel module, implementing the filesystem of the type "cachefs" > > and a character device /dev/cachefs > > - user-space daemon, which would communicate with the kernel > > over /dev/cachefs and which would manage the backing store > > in a given directory. > > > > Every file on the front filesystem (NFS or so) volume will be cached > > in two local files by cachefsd: The first one would contain the (parts of) > ... > > * Should the cachefsd be in user space (as it is in the prototype > > implementation) or should it be moved to the kernel space? The > > former allows probably better configuration (maybe a deeper > > directory structure in the backing store), but the later is > > faster as it avoids copying data between the user and kernel spaces. > > I think that, if speed is your goal, you should have the kernel > code use swap space for the cache. Look at what tmpfs does, but > running over top of tmpfs leaves you with the overhead of running > two filesystems and a daemon. It is better to be direct.
So how would you get persistent caching across reboots which is one of the major advantages of a cachefs type filesystem. I guess you could tar the cache on startup and shutdown although would be a little slow :).
I think 'speed' here means faster than NFS or other network filesystems - you obviously have the overhead of network traffic for cache-coherency but can avoid a lot of data transfer (even after a reboot).
~mc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |