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.tuomi...@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
