[OpenAFS] Re: caching local data?
kim.kimball@att.net
kim.kimball@att.net
Wed, 08 May 2002 17:27:03 +0000
*Per-file operations*
Such as cp, mv, read(), write(), flush(), close() etc ...
The AFS client issues per-file access requests -- for
per file access cacheing always occurs. (afsmonitor or
xstat utilities will show cache usage that reflects
this, if you want to experiment)
That is, the client requests a file from the file server
and caches the results.
The client doesn't care that the fileserver process is
collocated, and it's not clear that this logic would be
a good idea, since for heavily used files (where
cacheing benefits us most) the "don't cache" strategy
would only up the load on the fileserver itself --
affecting all users of the fileserver (processes), local
or otherwise.
*Per-volume*
Per-volume operations don't cause client-side cacheing.
Per-volume operations include vos move, vos dump ... etc.
--
---------------------
Dexter "Kim" Kimball
CCRE,
Inc.
kim@ccre.com
> Send OpenAFS-info mailing list submissions to
> openafs-info@openafs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openafs.org/mailman/listinfo/openafs-info
> or, via email, send a message with subject or body 'help' to
> openafs-info-request@openafs.org
>
> You can reach the person managing the list at
> openafs-info-admin@openafs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenAFS-info digest..."
>
>
> Today's Topics:
>
> 1. Re: caching local data? (Russ Allbery)
> 2. Re: ADSM(TSM) Backup (Russ Allbery)
> 3. Re: caching local data? (eichin-oa@boxedpenguin.com)
> 4. unable to map drives in the W2K client (Janine Ovens)
> 5. openafs on alpha linux (Nathan Davis)
> 6. Re: openafs on alpha linux (Marc Schmitt)
> 7. Re: openafs on alpha linux (Nathan Davis)
>
> --__--__--
>
> Message: 1
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] caching local data?
> From: Russ Allbery <rra@stanford.edu>
> Organization: The Eyrie
> Date: Tue, 07 May 2002 10:10:09 -0700
>
> Pete Shinners <pete@visionart.com> writes:
>
> > based on what we'll be doing on the network, i'm thinking i'll want
> > several of the beefier workstations on the network to be simple file
> > servers as well as clients. i'm hoping afs will ignore the cache when
> > the afs files are actually coming from a local disk? is that the case?
>
> I believe not; I believe that all AFS accesses go through the cache even
> if the volumes are also located on the same machine.
>
> > also, from everything i've read, it sounds best to keep the volume sizes
> > smaller and more manageable.
>
> Yes, it's recommended. Although we routinely create and use data volumes
> up to 2GB and even larger and don't have too many problems. Mostly it
> just shows up in taking a really long time to move volumes when we need
> to.
>
> We generally try to keep volume size down in the 500MB range when we can,
> and have a maximum of 2GB for data volumes (with a few exceptions) and 1GB
> for user home directories.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
>
> --__--__--
>
> Message: 2
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] ADSM(TSM) Backup
> From: Russ Allbery <rra@stanford.edu>
> Organization: The Eyrie
> Date: Tue, 07 May 2002 10:14:01 -0700
>
> Harald Barth <haba@pdc.kth.se> writes:
>
> > AFS backups can be done on
>
> > * File level
>
> This is what we're doing here at Stanford.
>
> > +per file restore
> > +users can do restores themselves
>
> We haven't gotten this far in automating things yet, although we're
> thinking about doing so.
>
> > +file access through cache manager faster than volume access
> > +you can restore to any kind of file system
>
> > -you need to authenticate on file level
> > one of
> > process runnig as system:administrator
> > process running as backupuser and you need to add "backupuser
> > read"everywhere
>
> We took the second approach, as well as wrapping fs so that the version on
> the typical user's PATH won't remove the backup user from the ACLs.
>
> > -running the client traversing volume mountpoints will not work as
> > there is no loop detection in the client
> > -running the client without traversing volume mountpoints: You need to
> > assure that all your volumes are mounted somewhere
>
> We took the latter approach, and took the simple approach of just creating
> a volume for mount points out in AFS and then mount each volume, back it
> up, and then remove the mount point again.
>
> > -AFS functionality does not exist in all TSM clients platforms for
> > which there was AFS available from the same company.
>
> We're doing our backups directly on the AIX backup server.
>
> --
> Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
>
> --__--__--
>
> Message: 3
> To: Russ Allbery <rra@stanford.edu>
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] caching local data?
> From: eichin-oa@boxedpenguin.com
> Date: 07 May 2002 14:01:30 -0400
>
> Indeed, due to the lack of good automatic volume splitting tools, I
> keep my debian mirror (x86+sparc+source, potato+woody) in a single 30G
> volume. It's non-backed-up, and never has to clone, so the size isn't
> an issue itself; if I do vos move it, well, the last large-volume
> tests I did showed vos move getting 80Mbit/s on a 100Mbit switched
> net, between two cheap PC's with 100G drives -- in other words, faster
> than most other mechanisms I'd use.
>
> --__--__--
>
> Message: 4
> Date: Tue, 7 May 2002 15:32:33 -0400
> From: "Janine Ovens" <eninaj@umich.edu>
> To: <openafs-info@openafs.org>
> Subject: [OpenAFS] unable to map drives in the W2K client
>
> I just finished installing OpenAFS for WindowsNT client 1.2.2b on a W2K =
> Pro workstation. After I am done configuring it I am able to start the =
> service without any problem, and I can get tokens, but as soon as I try =
> to map a drive, it returns the following error:
> "AFS was unable to map the network drive to the specified path in AFS. =
> Check to make sure the drive letter is not currently in use. Error: =
> 0x00000035"
>
> I tried using different drive letters, different paths, and even =
> different cells but they all return the same message. The drives show up =
> on the drive mapping list as being available, but as soon as I try to a) =
> add a drive in addition to the two default drives (/afs and =
> /afs/cellname/user) or b) click the checkbox next to a default drive =
> mapping it errors out. I am able to map a Windows network drive using =
> letters that return the error message through AFS. I have installed the =
> same client (1.2.2b) on another W2K workstation with no trouble. The =
> only main difference between the problem machine and my regular =
> workstation is that the former has a RAID card and three striped drives. =
> Any ideas?
>
> Thanks,
> Janine
>
> *************************************************************************=
> *****
> Janine Ovens
> Computer Systems Consultant
> Economics and Geology
> eninaj@umich.edu
>
> --__--__--
>
> Message: 5
> From: "Nathan Davis" <davi0709@tc.umn.edu>
> To: <openafs-info@openafs.org>
> Date: Tue, 7 May 2002 21:40:10 -0500
> Subject: [OpenAFS] openafs on alpha linux
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_000F_01C1F60F.C35BCC00
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> I'm trying to setup afs on my alpha box running the stock Redhat 7.1 =
> (kernel version 2.4.3-12). I got the latest source rpm, and did an rpm =
> --rebuild on it.
>
> 1) src/config/Makefile.alpha_linux24.in is =
> src/config/Makefile.alpha_linux_24.in instead. This causes the build to =
> bail out. My first question, therefore, is if this is intentional. Is =
> afs on alpha-linux not currently working, so the file is renamed so as =
> to make sure you really want to do it? Or is this just something that =
> was overlooked? Also, Makefile.alpha_linux_24.in only makes references =
> to 2.2 kernels (although only in comments). It has nothing relating to =
> 2.4 kernels (either commented or uncommented). I suspect that is just =
> because noone has bothered to change it yet.
>
> 2) Okay, so the quick fix in the short term was to hack the spec file so =
> that the alpha Makefile.in would be accessed (in other words, change how =
> the sysname variable was generated). This, of course, would cause =
> builds to fail on other architectures where the Makefile.in file is =
> "properly" named, but now the software builds on alpha-linux. A quick =
> question here is whether this might cause different pre-processor =
> variables/macros to be defined (thus causing code to be generated =
> differently than it should).
>
> 3) I got the binary RPMs built, and started to install -- fundamentally =
> following Quick Start Guide (specifically, the "Installing the First AFS =
> Machine" chapter), but obviously making adaptions (mostly skipping =
> parts) due to using RPM. Everything appears to go fine until I get to =
> the section "Initializing Cell Security." The problem is, after =
> creating "afs" in kas and executing the bos addkey commands, when I =
> compare the checksum they are different. Any ideas as to what is wrong? =
> I tried multiple times, even trying less than trivial passwords (to =
> make sure there was no mistake in typing), and they were different every =
> time.
>
> 4) Are there any "gotchas" when you want to start over? I.e., is there =
> anything special you need to do (files that need to be deleted that =
> aren't in /usr/afs or /usr/vice and aren't uninstalled automatically =
> when the rpm is uninstalled, etc.)? Could it help the problem?
>
> 5) What (if any) tools are available for installing and/or =
> administrating afs, beyond what is distributed with openafs? I just =
> want to know, so I can write them if they aren't available ;-).
>
> Thanks for bearing with me,
>
> --Nathan G. Davis
>
> ------=_NextPart_000_000F_01C1F60F.C35BCC00
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
> <HTML>
> <HEAD>
>
> <META content=3Dtext/html;charset=3Diso-8859-1 =
> http-equiv=3DContent-Type>
> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT color=3D#000000 size=3D2>Hi,</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>I'm trying to setup afs on my alpha =
> box running=20
> the stock Redhat 7.1 (kernel version 2.4.3-12). I got the latest =
> source=20
> rpm, and did an rpm --rebuild on it.</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>1) =
> src/config/Makefile.alpha_linux24.in is=20
> src/config/Makefile.alpha_linux_24.in instead. This causes the =
> build to=20
> bail out. My first question, therefore, is if this is =
> intentional. =20
> Is afs on alpha-linux not currently working, so the file is renamed so =
> as to=20
> make sure you really want to do it? Or is this just something that =
> was=20
> overlooked? Also, Makefile.alpha_linux_24.in only makes references =
> to 2.2=20
> kernels (although only in comments). It has nothing relating to =
> 2.4=20
> kernels (either commented or uncommented). I suspect that is just =
> because=20
> noone has bothered to change it yet.</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>2) Okay, so the quick fix in the =
> short term was=20
> to hack the spec file so that the alpha Makefile.in would be accessed =
> (in other=20
> words, change how the sysname variable was generated). This, of =
> course,=20
> would cause builds to fail on other architectures where the Makefile.in =
> file is=20
> "properly" named, but now the software builds on =
> alpha-linux. A=20
> quick question here is whether this might cause different pre-processor=20
> variables/macros to be defined (thus causing code to be generated =
> differently=20
> than it should).</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>3) I got the binary RPMs built, and =
> started to=20
> install -- fundamentally following Quick Start Guide (specifically, the=20
> "Installing the First AFS Machine" chapter), but obviously =
> making=20
> adaptions (mostly skipping parts) due to using RPM. Everything =
> appears to=20
> go fine until I get to the section "Initializing Cell =
> Security." =20
> The problem is, after creating "afs" in kas and executing the =
> bos=20
> addkey commands, when I compare the checksum they are different. =
> Any ideas=20
> as to what is wrong? I tried multiple times, even trying less than =
> trivial=20
> passwords (to make sure there was no mistake in typing), and they were =
> different=20
> every time.</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>4) Are there any "gotchas" =
> when you=20
> want to start over? I.e., is there anything special you need to do =
> (files=20
> that need to be deleted that aren't in /usr/afs or /usr/vice and aren't=20
> uninstalled automatically when the rpm is uninstalled, etc.)? =
> Could it=20
> help the problem?</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>5) What (if any) tools are available =
> for=20
> installing and/or administrating afs, beyond what is distributed with=20
> openafs? I just want to know, so I can write them if they aren't =
> available=20
> ;-).</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>Thanks for bearing with =
> me,</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
> <DIV><FONT color=3D#000000 size=3D2>--Nathan G. =
> Davis</FONT></DIV></BODY></HTML>
>
> ------=_NextPart_000_000F_01C1F60F.C35BCC00--
>
>
> --__--__--
>
> Message: 6
> Date: Wed, 08 May 2002 11:38:31 +0200
> From: Marc Schmitt <schmitt@inf.ethz.ch>
> To: Nathan Davis <davi0709@tc.umn.edu>
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] openafs on alpha linux
>
> Hi Nathan,
>
> I`ll give you the same advice as Jimmy gave me, because it worked on the
> ES40 I have here with kernel 2.4.9-31, just fyi. :)
>
> > Jimmy Engelbrecht wrote:
> >> Marc Schmitt <schmitt@inf.ethz.ch> writes:
> >>
> >>When can one expect a fully working client for Linux Alpha
> >>approximately?
> >>
> > no idea.
> > Have you tried arla ?
> >
> > http://www.stacken.kth.se/projekt/arla/
> >
> > /Jimmy
>
>
> Greetz
> Marc
>
>
> --__--__--
>
> Message: 7
> From: "Nathan Davis" <davi0709@tc.umn.edu>
> To: "Marc Schmitt" <schmitt@inf.ethz.ch>
> Cc: <openafs-info@openafs.org>
> Subject: Re: [OpenAFS] openafs on alpha linux
> Date: Wed, 8 May 2002 10:49:00 -0500
>
> Thanks for the info, Marc. Is it safe to assume that the server is not
> functional on alpha either? Anyone know what needs to be done to get it
> working?
>
> --Nathan Davis
>
> -----Original Message-----
> From: Marc Schmitt <schmitt@inf.ethz.ch>
> To: Nathan Davis <davi0709@tc.umn.edu>
> Cc: openafs-info@openafs.org <openafs-info@openafs.org>
> Date: Wednesday, May 08, 2002 4:38 AM
> Subject: Re: [OpenAFS] openafs on alpha linux
>
>
> >Hi Nathan,
> >
> >I`ll give you the same advice as Jimmy gave me, because it worked on the
> >ES40 I have here with kernel 2.4.9-31, just fyi. :)
> >
> > > Jimmy Engelbrecht wrote:
> > >> Marc Schmitt <schmitt@inf.ethz.ch> writes:
> > >>
> > >>When can one expect a fully working client for Linux Alpha
> > >>approximately?
> > >>
> > > no idea.
> > > Have you tried arla ?
> > >
> > > http://www.stacken.kth.se/projekt/arla/
> > >
> > > /Jimmy
> >
> >
> >Greetz
> > Marc
> >
> >
>
>
>
> --__--__--
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
> End of OpenAFS-info Digest