For your home cell I assume you are using DNS AFSDB records. 1.6 looks for DNS SRV records first, then fails over to AFSDB if they are not found. Publish DNS SRV records for your cell.
Jeffrey Altman On Dec 10, 2012, at 4:45 PM, [email protected] wrote: > > Thanks Jeffrey, that explains things nicely. Eventhough the dns-lookups > work, I suspect it is far from optimal. If the lookup takes a fair amount > of time on top of nautilus fetching the afs content itself, it can very > well be enough to cause the timeout. Once you can cache the location and > content enough, there's enough time for nautilus to succeed. > > BTW, I tried openafs 1.6. together with fakestat-all and dynroot-sparse a > bit earlier but nautilus behaved the same and unfortunately atleast the > login phase is still slower than in 1.4. (GDM & LDAP & AFS homedirs). > > I did receive a new error message which deals with dbus as well. > > (nautilus:12750): Unique-DBus-WARNING **: Error while sending message: Did > not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network connection was broken. > > This seems to be a symptom rather than the cause, so I'm still suspecting > DNS issues. > > Now, back to the investication... Thanks everybody! > > > br, jukka > > > > >> -fakestat provides no benefits if the application is going to read the >> contents of the volume root directory referenced by a mount point. >> -fakestat works by generating fake stat info for the mount point target >> instead of reading the actual data belonging to the target which might >> require a volume location database lookup in addition to the file server >> fetch status RPC. There might even need to be DNS queries to find the >> locations of the VLDB servers in the foreign cell. >> >> Jeffrey Altman >> >> >> On Dec 10, 2012, at 1:22 PM, [email protected] wrote: >> >>> >>> Hmmm... Strange things happened. After several hang-ups, being more >>> patient they turned into time-outs, until... even nautilus could get >>> through! First I thought that initiating nautilus from the command line >>> - >>> as part of strace command - did something, but then I could browse (in >>> veeeery slow motion) directly within nautilus. >>> >>> Now it seems more likely that eventhough fakestat does its thing within >>> the local cell (or is otherwise just faster), the same thing isn't >>> happening with the foreign cells (or it is just too slow). Once the dir >>> content is displayed, nautilus continues to dig deeper into subdirs on >>> the >>> background, adding the number of items one-by-one. So it seems it hasn't >>> scanned all-of-all before displaying the content!? >>> >>> Should fakestat-all instead of fakestat solve this situation? How >>> exactly >>> should I tweak the configuration to have it started on boot, and how can >>> I >>> verify that it is on? >>> >>> br, jukka >>> >>> >>> >>>> On Sun, Dec 9, 2012 at 3:37 PM, <[email protected]> wrote: >>>>> >>>>> By "own-path" I mean local cell as opposed to foreign one. >>>> >>>> Oh, this may not be the same issue then. On my computer I see the GUI >>>> freezes happening for my local cell. >>>> >>>> You can try running nautilus through strace or gdb to see what >>>> specifically is hanging: >>>> >>>> $ strace /usr/bin/nautilus >>>> >>>> You probably want to ensure no other Nautilus processes are running >>>> before you do that (ps -A | grep nautilus). >>>> >>>> It's possible Wireshark or tcpdump might tell you more as well. I >>>> would start by sniffing on the ports for DNS, Kerberos, and AFS: >>>> >>>> $ tcpdump "port 53 and port 88 and portrange 7000-7005" >>>> >>>> (or use that filter in Wireshark) >>>> >>>> - Ken >>>> _______________________________________________ >>>> OpenAFS-info mailing list >>>> [email protected] >>>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >>> >>> _______________________________________________ >>> OpenAFS-info mailing list >>> [email protected] >>> https://lists.openafs.org/mailman/listinfo/openafs-info >> >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
