[OpenAFS] Graphical file managers get stuck

[Troy Benjegerdes]

This seems to be a common cause of pain for people using AFS,
and I think its a user-interface experience that drives people
away.

You install AFS, and then all of a sudden you go do something
and your user-interface just hangs. You have not idea what 
triggered it, you just associate 'crappy non-responsive computer'
with this AFS thing.

Is there any reasonable way we can provide a global /afs namespace,
while still retaining good performance (i.e. under 100ms response
time when file managers to into /afs/*/)?

We can talk about client misconfiguration, or bad DNS , or bad
network, or whatever, but the buck's got to stop somewhere. How
can we provide fast response and still indicate somehow (with 
an AFS manager app/system tray???) that some servers may be 
inaccessible, slow, or misconfigured, but still not block when
file managers go look at things??

There should be a checkbox for "Yes, make me wait for responses
from servers in cell XXX, and give me an indication who you're
waiting for", otherwise non-local cells should probably just 
return whatever data they have, or just ENOTCONN 

On Mon, Dec 10, 2012 at 03:50:05PM -0500, Jeffrey Altman wrote:
> -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