SUMMARY Using cachefs as a fail-over mechanism

From: Brett Lymn (
Date: Thu Aug 10 2000 - 22:24:39 CDT

        A few days I posed this question:

> This is more a architecting question more than anything else.
>What I am looking at doing is working out how I can provide some
>robustness in some critical machines if a server goes down. We have
>some small nfs partitions containing our automount maps mounted from a
>central server, the concern is when this central server is down the
>other machines stop. Clearly undesirable. I cannot use YP to
>distribute the automount maps because the maps are different on each
>of the client machines which NIS automount maps do not deal with as
>far as I can tell. I have the automount maps gathered in one place
>for ease of administration so scattering them over the machines is not
>where I want to be either. Sooooo, what I am wondering is if I can
>use the cachefs to act as a local cache of the files, automagically
>updated from the server when they change, the only thing I am unsure
>about is the behaviour of cachefs when the nfs server is down. Will
>the cachefs layer use the cached object if the back filesystem file
>server is down? (assume that I am mounting the back file system

The short answer: I think I can make this work.... sort of, see below.

I got a wide range of answers to this one, which is what I expected
:-) Mostly, people suggested other methods of distributing the files
such as NIS or using rdist or rsync. Only one person, Luc Michaud,
said cachefs would not work because it maintains a connection to the
back file system.

By this time I had already tried the idea myself but it failed when I
disabled the network port to simulate an outage (note I mounted the
back filesystem over a second network interface so everything else
stayed up on the machine). After Luc's message I had a rethink and
reread of the mount_cachefs man page. The reason it was failing was
because cachefs was trying to get the file attributes from the server,
by using the "local-access" mount option I could bypass the attribute
check. Doing this I could cat a file to get it into the local
cachefs, disable the network interface and still cat the file! I
could not access anything NOT in the local cachefs cache but that is
fine by me. The only problem with this is that by default cachefs
validates the files in cache against the server periodically by
default. You can turn this off with either the "noconst" or
"demandconst" mount_cachefs options, using either of these options
would mean the file will stick in the cache and would be served up
regardless of whether the back filesystem server is up or not.

Now my dilemma is do I want to script the clients to check if the
filesystem is available and force a refresh periodically OR script the
server to distribute the files out somehow. I am leaning towards
scripting the clients on the basis that a server push is prone to a
machine getting dropped off the list and losing updates.

For interests sake, here are the mounts I made:

/mnt on miscsan:/ read only/soft/remote on Fri Aug 11 11:05:03 2000
/opt/test on /mnt backfstype=nfs/cachedir=/opt/cache/read only/backpath=/mnt/local-access/demandconst on Fri Aug 11 12:40:40 2000

Where /mnt is just a mount used for testing, /opt/test is the cached
filesystem mount.

Probably what I should really do is put in a RFE to Sun to put an
option into mount_cachefs that allows cachefs to serve up a, possibly
stale, file from cache if accessing the back filesystem fails.

Many thanks to the following for their thoughts and insights (and a
big raspberry to all the llamas out there who cannot set up their
vacation responder properly):

Luc Michaud
Jason Armbruster
Ravi Kuppanna
Nate Itkin
Thomas Wardman
Vince Taluskie

U BEFORE POSTING please READ the FAQ located at
. and the list POLICY statement located at
A To submit questions/summaries to this list send your email message to:
A To unsubscribe from this list please send an email message to:
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:14 CDT