[OpenAFS] Graphical file managers get stuck
Stephan Wiesand
stephan.wiesand@desy.de
Mon, 10 Dec 2012 19:33:52 +0100
On Dec 10, 2012, at 19:22 , 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.
>=20
> 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!?
Graphical file managers like Nautilus (that tend to dig deeply into =
whatever they see) and worldwide filesystems like AFS just don't play =
well together.
> Should fakestat-all instead of fakestat solve this situation?
Most likely, no.
We've been using dynroot-sparse since it became available with 1.6, and =
it *does* help a lot.
Regards,
Stephan
> How exactly
> should I tweak the configuration to have it started on boot, and how =
can I
> verify that it is on?
>=20
> br, jukka
>=20
>=20
>=20
>> On Sun, Dec 9, 2012 at 3:37 PM, <jukka.tuominen@finndesign.fi> =
wrote:
>>>=20
>>> By "own-path" I mean local cell as opposed to foreign one.
>>=20
>> Oh, this may not be the same issue then. On my computer I see the GUI
>> freezes happening for my local cell.
>>=20
>> You can try running nautilus through strace or gdb to see what
>> specifically is hanging:
>>=20
>> $ strace /usr/bin/nautilus
>>=20
>> You probably want to ensure no other Nautilus processes are running
>> before you do that (ps -A | grep nautilus).
>>=20
>> 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:
>>=20
>> $ tcpdump "port 53 and port 88 and portrange 7000-7005"
>>=20
>> (or use that filter in Wireshark)
>>=20
>> - Ken
--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany