| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9409.1 | | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Mon Apr 07 1997 14:16 | 20 |
| We don't.
A cacheing file system is a local file system that acts as
a cache for an NFS mounted remote file system. As files
are read from the remote file system, they are written
on the local file system. Future reads (when not immediately
satisfied by the local system's buffer cache), are satisfied
by the cacheing file system. I don't know how the cacheing
file systems handle writes or doing file replacement when
the cache becomes full.
I suspect Sun's need for a caching file system grew out of
their reliance on diskless client systems. System speeds
increased much faster than network speeds and often such
systems were hobbled waiting on network I/O. The caching
file system was a way to get the files read from the server
with great frequency (but not so great as to live in the
buffer cache) on the local system for quick access. But,
unlikely have a local partial system disk, only the files
that were needed would be cached.
|
| 9409.2 | Re: cachefs with NFS servers | QUABBI::"[email protected]" | | Thu Apr 10 1997 21:33 | 26 |
| [email protected] (Dr. File System's Home for Wayward Inodes.) writes:
>Title: cachefs with NFS servers
> I suspect Sun's need for a caching file system grew out of
> their reliance on diskless client systems.
CacheFS would be really, really handy in our development arena. Our kernel
builds are done with most source and object code coming from NFS
servers usually on the other side of a lossy router. A kernel build
will completely wipe out the UBC caches on a 96 MB system. If we
had cacheFS, the first build in the morning would pick up all the new
object files and headers from the nightly build and few reads and writes
would thereafter flow on our 10Base2 network.
I added a readlink cache to NFS cut the number of readlinks per compile
from about 30,000(!) to 5, then had to increase the size of the file name
we would cache because "sterling.nightly" or whatever was too long. We're
adding a negative name cache to NFS for Steel. Watching builds while
running tcpdump is truly appalling!
But, no, no plans for cacheFS or autofs.
--
<> Eric (Ric) Werme <> This space under reconstruction <>
<> <[email protected]> <> <>
[posted by Notes-News gateway]
|
| 9409.3 | customer interest | ASABET::SILVERBERG | My Other O/S is UNIX | Fri Apr 11 1997 07:13 | 5 |
| Interesting ---Abbott Labs asked for cachefs on Digital UNIX, but
we had to respond with the above message.
Mark
|
| 9409.4 | Dare I suggest... | SMURF::STRANGE | Steve Strange, UNIX Filesystems | Mon Apr 21 1997 18:33 | 10 |
| You want disk-based client caching? Use DCE/DFS! As side benefits,
you'll also get real security, cache coherency, and a global namespace.
DFS has been available on DU for nearly three years. And it's free
with a base OS license (although you do need DCE, which isn't entirely
free).
OK, got in my DFS plug. Back to your regularly-scheduled programming.
:-)
Steve
|