From: Michael Clark <michael@metaparadigm.com>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: Jan Kasprzak <kas@informatics.muni.cz>,
linux-kernel@vger.kernel.org, xgajda@fi.muni.cz, kron@fi.muni.cz
Subject: Re: CacheFS
Date: Fri, 08 Jun 2001 13:15:13 +0800 [thread overview]
Message-ID: <3B205F61.A5820A37@metaparadigm.com> (raw)
In-Reply-To: <200106072223.f57MNxh414151@saturn.cs.uml.edu>
"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
next prev parent reply other threads:[~2001-06-08 5:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-07 11:37 CacheFS Jan Kasprzak
2001-06-07 15:44 ` CacheFS Jan Harkes
2001-06-08 11:48 ` CacheFS Jan Kasprzak
2001-06-09 8:29 ` CacheFS Pavel Machek
2001-06-07 22:23 ` CacheFS Albert D. Cahalan
2001-06-08 5:15 ` Michael Clark [this message]
[not found] <200603232313.k2NNDEW2006900@shell0.pdx.osdl.net>
2006-03-23 23:20 ` cachefs sv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B205F61.A5820A37@metaparadigm.com \
--to=michael@metaparadigm.com \
--cc=acahalan@cs.uml.edu \
--cc=kas@informatics.muni.cz \
--cc=kron@fi.muni.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=xgajda@fi.muni.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).