[OpenAFS] Graphical file managers get stuck

[jukka.tuominen@finndesign.fi]

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, jukka.tuominen@finndesign.fi 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,  <jukka.tuominen@finndesign.fi> 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
>>> 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
>