Re: [OpenAFS] AFS lag
Derrick Brashear wrote: On Wed, Mar 18, 2009 at 9:56 PM, Ken Hornstein wrote: I'm no ubik engineer, but as far as I understand it, the protocol was not designed for even numbers of participating servers. For best results, three or five servers seem to be optimum. I hear this frequently, and don't see why it should be true. The tie breaking mechanism during an election is simple. Kim There is a lot of misinformation about Ubik out there; the voting protocol is actually not complicated, it's just not documented well. it's actually well-documented, if you find Kazar's paper on Quorum Completion. If your database servers are accessable via the Internet, we could take a look at them via udebug. Really, there are only a few things that can go wrong; of all of the pieces of AFS, I think Ubik is one of the most bulletproof. There are a couple (unlikely) open issues; See RT. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS, Cisco VPN and MAC OS and mtu
Have you tried setting MTU on the fileserver command line instead? That's what we've done, for the same reason. It has worked, and we don't have to fiddle with each client. The negotiation between AFS client and fileserver for MTU size is "fileserver wins." Kim Kimball Douglas E. Engert wrote: We are having problems with Mac OS 10.4 and 10.5 using Cisco VPN AFS can become unusable. Mac 10.4 is running OpenAFS 1.4.8 for sure. I think the Mac 10.5 is running OpenAFS 1.5.59. Using rxdebug and looking at the natMTU parameter, on most Unix systems this is 1444,(1500 - 56) as expected. On Windows systems this is usually 1260. And on MAC it is 1444. Even if I set the interface mtu 1244, and reboot the MAC, rxdebug shows the interface is using 1244 but rxdebug continues to show a natMTU = 1444. as though it still assumed the mtu was 1500. So it looks like the MAC client is not getting the existingMTU from the OS in util/netutils.c The AFS client on Windows has the RxMaxMTU (1244 appears to be the best setting). Is there any equivelent option for the MAC? Any thoughts on this? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Selecting a configuration file format for OpenAFS Services
Jason Edgecombe wrote: David Boyes wrote: On 5/16/09 12:33 AM, "Jeffrey Altman" wrote: OpenAFS does not have a configuration file for use by administrators to configure the various services. As a result, each time a new configuration option is created it has been implemented either as a compile time option or a run time option controlled by a command-line switch. The gatekeepers are opposed to the addition of new compile time options because it puts packagers in the position of determining what features administrators and end users are able to deploy without building from source. However, additional command-line parameters have their own complexity issues. For example, the current fileserver command line has approximate forty options; many of which are no longer optional for reasonable deployment configurations. Rather than scattering configuration around in files, I'd like to see a configuration daemon that maintained the configurations for the various pieces. A single command line argument identifying a set of addresses to contact a config daemon would make this very simple to implement, and the config daemon could be a simple "connect, id yourself, receive your config, disconnect" operation. Would make configuration management a lot simpler. If you insist on files, then all configuration should be possible within the files, and the command line args should be frozen as is for backward compatibility. The Kerberos file format is as good as any, although not really friendly for complex parms. I'd prefer one or more files as opposed to one more daemon. You can use cfengine, puppet, etc to distribute configs. I suggest putting the file in the same folder as CellServDB. Jason ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info the server afs/local directory might be better for server config Kim ___ 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
What kernel version is that? 2.6.27.21-0.1 How are your feelings about that? Do you think trying the compile with OpenSuSE 10.3 will work? Instead of making changes to the kernel source. _ "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] Unable to start afs on OpenSuSE 11.1
> I compiled OpenAFS 1.4.10 on ppc running OpenSuSE 11.1. Everything seemed to > compile fine, but when I try to start afs I get this message in > /var/log/messages: > > kernel: libafs: Unknown symbol do_signal First the standard questions: What kernel version is that? There might be a slight risk that you'll have to compile the SuSE kernel but with a small modification in the source code. How are your feelings about that? (As a IBM only supports ancient SuSE together with a BlueGene, I don't have any experience of OpenAFS on ppc with modern SuSE) Harald. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Unable to start afs on OpenSuSE 11.1
I compiled OpenAFS 1.4.10 on ppc running OpenSuSE 11.1. Everything seemed to compile fine, but when I try to start afs I get this message in /var/log/messages: kernel: libafs: Unknown symbol do_signal Any help will be appreciated. Thanks! _ "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] PTS sadness
> Finally, prdb_check claims the new database has more problems than the > original, and that's a show-stopper. I'm now at a loss for future > direction. db_verify has an option to generate a "recreate" file that can be fed into ptclient to recreate the database. I run that command one a year so I can grep the database for historical lookups. If only ptserver had some logging. I also use adb -w to debug my ptserver database. The records are all fixed length, and their positions in the database file do not change. The group entries contain member information, and the member entries contain group information. Some times these two are not in sync, and adb can be used to zero out the "bad" information. Crude, but it does work. Try db_verify/ptclient and report back. Thanks. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Volumes offlined during reclone
Hi Jeffrey! On Mon, 25 May 2009, Jeffrey Altman wrote: Stephan Wonczak wrote: Hi all! On two consecutive weekends we had volumes going offline on one of our just-upgraded 1.4.10 fileservers. This seems to happen during the nightly 'vos backupsys'-runs. The effect is that the 'salvage' flag is set on one or two volumes, effectively bringing them offline. Thanks to Derrick this is fixed by http://www.openafs.org/cgi-bin/wdelta/openafs-stable-1_4_x/STABLE14-background-fsync-consistency-issues-20090522?diff Ah, great. So it was a bug after all. Kudos to Derrick for fixing this. Any idea when a fixed 1.4.11 will be available? This bug is a kind of showstopper for us. Dipl. Chem. Dr. Stephan Wonczak Regionales Rechenzentrum der Universitaet zu Koeln (RRZK) Universitaet zu Koeln, Robert-Koch-Strasse 10, 50931 Koeln Tel: +49/(0)221/478-5577, Fax: +49/(0)221/478-5590 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
