[528] in Info-AFS_Redistribution
Re: some questions about using AFS to share core OS files
daemon@ATHENA.MIT.EDU (Lyle_Seaman@transarc.com)
Wed Jan 15 20:23:26 1992
Date: Wed, 15 Jan 1992 18:42:58 -0500 (EST)
From: Lyle_Seaman@transarc.com
To: Info-AFS@transarc.com
In-Reply-To: <sdR9yWb0BwwyEgDwEN@transarc.com>
Joseph_Jackson@transarc.com writes:
> [ ... stuff about package ... ]
>
> To recover from a
> crashed client disk, you don't need to recover from backup tapes.
> Instead, install the operating system with enough of AFS to get the
> /afs mount point available, then run package.
>
> [ ... more stuff about package ... ]
No errors here, but it's worth pointing out that most vendors'
installation procedures don't exactly make this easy. In order to
pull this off, you usually have to spend some time paring down what
the vendor thinks is a minimal configuration, and then make a backup
when you're done.
In regard to the earlier comments about reliability and availability,
it should be clear that by replicating binaries on multiple servers
and distributing the servers throughout your network, you can achieve
very high availability, and protect against network partition. (ie,
the probability that all the servers will be unavailable at the same
instant is approximately (1- mean server availability)**NSERVERS)
Conceptually, all that you are doing by putting non-vital files in the
local filesystem on a client workstation is caching them outside of
AFS, and taking disk space away from your cache. Various studies have
shown (sorry, no references off the top of my head) that people
usually do worse at managing a cache than LRU. There are a few
reasons that you might want to do so anyway.
1. performance. Because AFS uses the local filesystem for caching, it
is not easy for us to achieve performance better than the local
filesystem. On a machine with lots of RAM and a VM-integrated
filesystem, this is less of an issue, and the difference gets smaller
every month.
2. reliability. If your network is very unreliable or your servers
are, you might choose to trade a few points of failure for many. This
can be mitigated by proper administration.
3. price. If lots of disks are cheaper than a few server boxes and
some extra network bandwidth, there's not much point in using a
distributed file system for stuff that changes infrequently.
Note that once a file is copied from a read-only volume to a
workstations cache, there is very little subsequent network traffic
to support that cached file, unless it gets flushed from the cache.
Absent explicit action by a user, that should only happen when the
cache space is needed for something "more important". If that
happens, you're better off without that file on the workstations disk,
since the space can obviously be better used. In other words, if you
choose to put that file in your local filesystem instead of the cache,
and diminish the cache size, you're effectively pinning an
infrequently hit file in the cache, reducing the cache hit rate.
Lyle Transarc 707 Grant Street
412 338 4474 The Gulf Tower Pittsburgh 15219
