[OpenAFS] Graphical file managers get stuck
Mon, 10 Dec 2012 15:50:05 -0500
-fakestat provides no benefits if the application is going to read the conte=
nts of the volume root directory referenced by a mount point. -fakestat wor=
ks by generating fake stat info for the mount point target instead of readin=
g the actual data belonging to the target which might require a volume locat=
ion database lookup in addition to the file server fetch status RPC. There m=
ight even need to be DNS queries to find the locations of the VLDB servers i=
n the foreign cell. =20
On Dec 10, 2012, at 1:22 PM, firstname.lastname@example.org 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@example.com> 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 mailing list