Messages in this thread |  | | | From | Jan Kasprzak <> | | Date | Thu, 7 Jun 2001 13:37:50 +0200 | | Subject | CacheFS |
| |
Hello,
a friend of mine has developed the CacheFS for Linux. His work is a prototype read-only implementation for Linux 2.2.11 or so. I am thinking about adapting (or partly rewriting) his work for Linux 2.4. But before I'll start working, I'd like to ask you for comments on the proposed CacheFS architecture.
The goal is to speed-up reading of potentially slow filesystems (NFS, maybe even CD-based ones) by the local on-disk cache in the same way IRIX or Solaris CacheFS works. I would expect this to be used on clusters of computers or university computer labs with NFS-mounted /usr or some other read-only filesystems. 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).
The CacheFS architecture would consist in two components: - 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) real file content, and the second one would contain file's metadata and the bitmap of valid blocks (or pages) of the first file. All files in cachefsd's backing store would be in a per-volume directory, and will be numbered by the inode number from the front filesystem.
Now here are some questions:
* 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.
* Would you suggest to have only one instance of cachefsd, or one per volume, or a multithreading implementation with configurable number of threads?
* Is the communication over the character device appropriate? Another alternative is probably a new syscall, /proc file, or maybe even an ioctl on the root directory of the filesystem (ugh!).
* Can the kernel part of CODA can be used for this?
Thanks,
-Yenya
-- \ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// It is a very bad idea to feed negative numbers to memcpy. --Alan Cox - 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/
|  |