It helps if you have an empty CellServDB. That way you won't have a bunch of cells in /afs and you can still go to cells that have correct DNS records when you need to.
On Mon, Dec 10, 2012 at 10:10 PM, Troy Benjegerdes <ho...@hozed.org> wrote: > 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.tuomi...@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.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 > > > > _______________________________________________ > > 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 > >
