Re: [OpenAFS] freebsd client
Hi, The client supports 7.0, on i386 and amd64 (and a number of prior releases). There is at least one significant open issue at 7.x and 8-CURRENT, that hopefully will be resolved fairly soon. Matt - Original Message - From: "Jerry McAllister" To: "Derrick Brashear" Cc: "ENEM|Hans Melgers" , openafs-info@openafs.org Sent: Tuesday, June 2, 2009 12:43:29 PM GMT -05:00 US/Canada Eastern Subject: Re: [OpenAFS] freebsd client On Tue, Jun 02, 2009 at 12:03:39PM -0400, Derrick Brashear wrote: > On Tue, Jun 2, 2009 at 6:12 AM, ENEM | Hans Melgers wrote: > > Hello, > > > > > > > > I was wondering if there have been any changes in the status of the openafs > > freebsd client, is it ready for production now ? > > It depends which version of FreeBSD, but we are distributing a stable > and working version from Matt Benjamin as of OpenAFS 1.4.8. How about FreeBSD 7.2 RELEASE -- or even 8.0 (Current)? jerry > > Derrick > ___ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] freebsd client
On Tue, Jun 02, 2009 at 12:03:39PM -0400, Derrick Brashear wrote: > On Tue, Jun 2, 2009 at 6:12 AM, ENEM | Hans Melgers wrote: > > Hello, > > > > > > > > I was wondering if there have been any changes in the status of the openafs > > freebsd client, is it ready for production now ? > > It depends which version of FreeBSD, but we are distributing a stable > and working version from Matt Benjamin as of OpenAFS 1.4.8. How about FreeBSD 7.2 RELEASE -- or even 8.0 (Current)? jerry > > Derrick > ___ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Unable to start afs on OpenSuSE 11.1
> This should be fixed in the openafs code - the right fix would > probably be to add a configure check for the availability of > do_signal, and define out the probing code if it's not available, > similar to what was done for init_mm. I haven't had luck with changing the SuSE kernel yet, so if you get a chance to give me a new configure file that would be great. Would it be exactly what is done with init_mm? If so, maybe I could manually change the configure script. _ "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." _ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] freebsd client
On Tue, Jun 2, 2009 at 6:12 AM, ENEM | Hans Melgers wrote: > Hello, > > > > I was wondering if there have been any changes in the status of the openafs > freebsd client, is it ready for production now ? It depends which version of FreeBSD, but we are distributing a stable and working version from Matt Benjamin as of OpenAFS 1.4.8. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Resilience
Wheeler, JF (Jonathan) wrote: One of our (3) AFS servers has a mounted read-write volume which must be available 24x7 to our batch system. The server is as resilient is we can make it, but still it may fail outside normal working hours for some reason. For technical reasons related to the software installed on the volume it is not possible to use read-only volumes mounted from our other servers (the software must be installed and served from the same directory name), so I have devised the following plan in the event of a failure: The way I read the above, is that only during install do you need write access to the sofware. After the install, do you still need write access to all or part of the software? If so can you put the write part on its own RW volume, but keep the rest replicated? Symlinks for selected files to the files in tghe RW volume could be used. With many open source packages, you can use --prefix, DESTDIR= and -rpath to force the install to be into /afs/.site/... but look in /afs/site/... Or on the first install, don't have any read only volumes, then the install is done to /afs/site/... After install, then replicate... It does not sound like this software changes very often. a) create read-only volumes on the other 2 servers, but do not mount them; use "vos release" whenever the software is updated b) in the event of a failure of server1 (which has the rw volume), drop the existing mount and mount one of the read-only volumes (we can live with the read-only copy whilst server1 is being repaired/replaced) in its place. If you can live with RO while it is being repaired, why can't you live with it with longer? That sounds like there is no requirement for RW. Can anyone see problems with that scenario ? We could use "vos convertROtoRW"; how would that affect the process ? Jonathan Wheeler e-Science Centre Rutherford Appleton Laboratory -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] it displays "?" marks in front of files info.
> is this normal? Yes. > does "list" permission can read file size? thank you. To do stat() system call on files, r(ead) permission ist needed. The file size is part of that information from stat(), see 'man 2 stat'. Harald. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Resilience
Wheeler, JF (Jonathan) wrote: > One of our (3) AFS servers has a mounted read-write volume which must be > available 24x7 to our batch system. The server is as resilient is we > can make it, but still it may fail outside normal working hours for some > reason. For technical reasons related to the software installed on the > volume it is not possible to use read-only volumes mounted from our > other servers (the software must be installed and served from the same > directory name), so I have devised the following plan in the event of a > failure: > > a) create read-only volumes on the other 2 servers, but do not mount > them; use "vos release" whenever the software is updated > b) in the event of a failure of server1 (which has the rw volume), drop > the existing mount and mount one of the read-only volumes (we can live > with the read-only copy whilst server1 is being repaired/replaced) in > its place. > > Can anyone see problems with that scenario ? We could use "vos > convertROtoRW"; how would that affect the process ? Volumes "app" and "app.readonly" have not only different names but different volume ids. Once an application has opened a directory or file on "app" it will continue to try to access the "app" volume even after the "app" volume is no longer present. Changing a mount point to refer to "app.readonly" will only affect future attempts to evaluate the path that resulted in "app" being accessed. The behavior you are looking for requires that the client believe that there is an alternate location for the "app" volume to failover to. In other words, you require that there be read-write replicas. This support does not currently exist. Using convertROtoRW will not provide the equivalence of a read-write replica because the client that is currently accessing the "app" volume on the one and only file server that the vlserver claimed the volume is located on. When the vldb is updated, the client will not receive any indication that the change occurred. During a volume move operation that notification would have come from the file server from which the volume was being moved. Of course, that file server is no longer responsive and is not involved in the move. Volume location information is valid for two hours but can be manually invalidated on the client using the "fs checkvolumes" command. During the 2009 Google Summer of Code some progress was made towards implementing a read-write replication model. If you are aware of resources that could be contributed to help complete this effort, please contact the OpenAFS gatekeepers. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Resilience
if you're aiming for 100% "guaranteed" availability for those RW volumes, a few other considerations: - make the volumes as small as practical, to keep the 'vos' operations short - make your afs database servers equally robust - make sure your network people provide the same level of robustness in the routers and stuff that the afs servers rely on afs is awesome, but it depends on the underlying network and power (something you might forget until you can't forget...) anne Wheeler, JF (Jonathan) wrote: One of our (3) AFS servers has a mounted read-write volume which must be available 24x7 to our batch system. The server is as resilient is we can make it, but still it may fail outside normal working hours for some reason. For technical reasons related to the software installed on the volume it is not possible to use read-only volumes mounted from our other servers (the software must be installed and served from the same directory name), so I have devised the following plan in the event of a failure: a) create read-only volumes on the other 2 servers, but do not mount them; use "vos release" whenever the software is updated b) in the event of a failure of server1 (which has the rw volume), drop the existing mount and mount one of the read-only volumes (we can live with the read-only copy whilst server1 is being repaired/replaced) in its place. Can anyone see problems with that scenario ? We could use "vos convertROtoRW"; how would that affect the process ? Jonathan Wheeler e-Science Centre Rutherford Appleton Laboratory ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Status of cache after server restart
Wheeler, JF (Jonathan) wrote: > I would like to know what is the status of the AFS cache on client > machines if an AFS server is restarted. Is the cache status for volumes > mounted from that server marked invalid/out-of-date, so that access to > such volumes requires a refresh from the server ? > > Jonathan Wheeler > e-Science Centre > Rutherford Appleton Laboratory In response to first RPC received from an otherwise unrecognized client the file server will send an InitCallBackState RPC which instructs the client to invalidate any status information previously obtained from that file server in the past. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] freebsd client
Hello, I was wondering if there have been any changes in the status of the openafs freebsd client, is it ready for production now ? Regards, Hans
Re: [OpenAFS] Resilience
Wheeler, JF (Jonathan) wrote: > One of our (3) AFS servers has a mounted read-write volume which must be > available 24x7 to our batch system. The server is as resilient is we > can make it, but still it may fail outside normal working hours for some > reason. For technical reasons related to the software installed on the > volume it is not possible to use read-only volumes mounted from our > other servers (the software must be installed and served from the same > directory name), so I have devised the following plan in the event of a > failure: > > a) create read-only volumes on the other 2 servers, but do not mount > them; use "vos release" whenever the software is updated > b) in the event of a failure of server1 (which has the rw volume), drop > the existing mount and mount one of the read-only volumes (we can live > with the read-only copy whilst server1 is being repaired/replaced) in > its place. > > Can anyone see problems with that scenario ? We could use "vos > convertROtoRW"; how would that affect the process ? The problem with convertROtoRW is that a dying fileserver doesn't send callbacks to the client as would happen when you move the RW-volume to another place. So you will have to do a "fs checkvol" on all clients to make sure they don't wait forever for the broken server, but use instead the newly created RW-volume. Our backup strategy is completely based on the possibility to do convertROtoRW. CRON jobs on the batch worker do the "fs checkvol" once in a while... Hartmut > > Jonathan Wheeler > e-Science Centre > Rutherford Appleton Laboratory > > -- - Hartmut Reuter e-mail reu...@rzg.mpg.de phone+49-89-3299-1328 fax +49-89-3299-1301 RZG (Rechenzentrum Garching)webhttp://www.rzg.mpg.de/~hwr Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) - ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Status of cache after server restart
I would like to know what is the status of the AFS cache on client machines if an AFS server is restarted. Is the cache status for volumes mounted from that server marked invalid/out-of-date, so that access to such volumes requires a refresh from the server ? Jonathan Wheeler e-Science Centre Rutherford Appleton Laboratory -- Scanned by iCritical. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Resilience
One of our (3) AFS servers has a mounted read-write volume which must be available 24x7 to our batch system. The server is as resilient is we can make it, but still it may fail outside normal working hours for some reason. For technical reasons related to the software installed on the volume it is not possible to use read-only volumes mounted from our other servers (the software must be installed and served from the same directory name), so I have devised the following plan in the event of a failure: a) create read-only volumes on the other 2 servers, but do not mount them; use "vos release" whenever the software is updated b) in the event of a failure of server1 (which has the rw volume), drop the existing mount and mount one of the read-only volumes (we can live with the read-only copy whilst server1 is being repaired/replaced) in its place. Can anyone see problems with that scenario ? We could use "vos convertROtoRW"; how would that affect the process ? Jonathan Wheeler e-Science Centre Rutherford Appleton Laboratory -- Scanned by iCritical. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
