[OpenAFS] Graphical file managers get stuck

[Derrick Brashear]

Guess what -dynroot-sparse does.

On Mon, Dec 10, 2012 at 4:24 PM, Mattias Pantzare <pantzer@ludd.ltu.se> wrote:
> 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 <hozer@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.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
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>
>



-- 
Derrick