[OpenAFS] Graphical file managers get stuck
Mattias Pantzare
pantzer@ludd.ltu.se
Mon, 10 Dec 2012 22:24:44 +0100
--047d7b339c87b0ddca04d08631ca
Content-Type: text/plain; charset=ISO-8859-1
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
>
>
--047d7b339c87b0ddca04d08631ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif=
;font-size:13px;line-height:18px">It helps if you have an empty=A0</span><s=
pan style=3D"font-size:13px;color:rgb(0,0,0);font-family:arial,helvetica,sa=
ns-serif;line-height:18px">CellServDB. That way you won't have a bunch =
of cells in /afs and you can still go to cells that have correct DNS record=
s when you need to.</span></div>
<div class=3D"gmail_extra"><br><br><br><div class=3D"gmail_quote">On Mon, D=
ec 10, 2012 at 10:10 PM, Troy Benjegerdes <span dir=3D"ltr"><<a href=3D"=
mailto:hozer@hozed.org" target=3D"_blank">hozer@hozed.org</a>></span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This seems to be a common cause of pain for =
people using AFS,<br>
and I think its a user-interface experience that drives people<br>
away.<br>
<br>
You install AFS, and then all of a sudden you go do something<br>
and your user-interface just hangs. You have not idea what<br>
triggered it, you just associate 'crappy non-responsive computer'<b=
r>
with this AFS thing.<br>
<br>
Is there any reasonable way we can provide a global /afs namespace,<br>
while still retaining good performance (i.e. under 100ms response<br>
time when file managers to into /afs/*/)?<br>
<br>
We can talk about client misconfiguration, or bad DNS , or bad<br>
network, or whatever, but the buck's got to stop somewhere. How<br>
can we provide fast response and still indicate somehow (with<br>
an AFS manager app/system tray???) that some servers may be<br>
inaccessible, slow, or misconfigured, but still not block when<br>
file managers go look at things??<br>
<br>
There should be a checkbox for "Yes, make me wait for responses<br>
from servers in cell XXX, and give me an indication who you're<br>
waiting for", otherwise non-local cells should probably just<br>
return whatever data they have, or just ENOTCONN<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Mon, Dec 10, 2012 at 03:50:05PM -0500, Jeffrey Altman wrote:<br>
> -fakestat provides no benefits if the application is going to read the=
contents of the volume root directory referenced by a mount point. =A0-fak=
estat 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 v=
olume location database lookup in addition to the file server fetch status =
RPC. =A0There might even need to be DNS queries to find the locations of th=
e VLDB servers in the foreign cell.<br>
><br>
> Jeffrey Altman<br>
><br>
><br>
> On Dec 10, 2012, at 1:22 PM, <a href=3D"mailto:jukka.tuominen@finndesi=
gn.fi">jukka.tuominen@finndesign.fi</a> wrote:<br>
><br>
> ><br>
> > Hmmm... Strange things happened. After several hang-ups, being mo=
re<br>
> > patient they turned into time-outs, until... even nautilus could =
get<br>
> > through! First I thought that initiating nautilus from the comman=
d line -<br>
> > as part of strace command - did something, but then I could brows=
e (in<br>
> > veeeery slow motion) directly within nautilus.<br>
> ><br>
> > Now it seems more likely that eventhough fakestat does its thing =
within<br>
> > the local cell (or is otherwise just faster), the same thing isn&=
#39;t<br>
> > happening with the foreign cells (or it is just too slow). Once t=
he dir<br>
> > content is displayed, nautilus continues to dig deeper into subdi=
rs on the<br>
> > background, adding the number of items one-by-one. So it seems it=
hasn't<br>
> > scanned all-of-all before displaying the content!?<br>
> ><br>
> > Should fakestat-all instead of fakestat solve this situation? How=
exactly<br>
> > should I tweak the configuration to have it started on boot, and =
how can I<br>
> > verify that it is on?<br>
> ><br>
> > br, jukka<br>
> ><br>
> ><br>
> ><br>
> >> On Sun, Dec 9, 2012 at 3:37 PM, =A0<<a href=3D"mailto:jukk=
a.tuominen@finndesign.fi">jukka.tuominen@finndesign.fi</a>> wrote:<br>
> >>><br>
> >>> By "own-path" I mean local cell as opposed to f=
oreign one.<br>
> >><br>
> >> Oh, this may not be the same issue then. On my computer I see=
the GUI<br>
> >> freezes happening for my local cell.<br>
> >><br>
> >> You can try running nautilus through strace or gdb to see wha=
t<br>
> >> specifically is hanging:<br>
> >><br>
> >> $ strace /usr/bin/nautilus<br>
> >><br>
> >> You probably want to ensure no other Nautilus processes are r=
unning<br>
> >> before you do that (ps -A | grep nautilus).<br>
> >><br>
> >> It's possible Wireshark or tcpdump might tell you more as=
well. I<br>
> >> would start by sniffing on the ports for DNS, Kerberos, and A=
FS:<br>
> >><br>
> >> $ tcpdump "port 53 and port 88 and portrange 7000-7005&q=
uot;<br>
> >><br>
> >> (or use that filter in Wireshark)<br>
> >><br>
> >> - Ken<br>
> >> _______________________________________________<br>
> >> OpenAFS-info mailing list<br>
> >> <a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@open=
afs.org</a><br>
> >> <a href=3D"https://lists.openafs.org/mailman/listinfo/openafs=
-info" target=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs=
-info</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenAFS-info mailing list<br>
> > <a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.=
org</a><br>
> > <a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-inf=
o" target=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-inf=
o</a><br>
><br>
> _______________________________________________<br>
> OpenAFS-info mailing list<br>
> <a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</=
a><br>
> <a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" ta=
rget=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a>=
<br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a><br>
<br>
</div></div></blockquote></div><br></div><div class=3D"gmail_extra"><br></d=
iv>
--047d7b339c87b0ddca04d08631ca--