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, [email protected] 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 protected]> 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 > >> [email protected] > >> https://lists.openafs.org/mailman/listinfo/openafs-info > > > > > > _______________________________________________ > > OpenAFS-info mailing list > > [email protected] > > https://lists.openafs.org/mailman/listinfo/openafs-info > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
