Bug 187088 - webdav navigation is very slow in FC5, used to be good in FC4
webdav navigation is very slow in FC5, used to be good in FC4
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nautilus (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomáš Bžatek
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-28 08:14 EST by Marius Andreiana
Modified: 2015-03-03 17:28 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 11:40:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marius Andreiana 2006-03-28 08:14:36 EST
(I'm not sure if this should filed against gnome-vfs)
After a clan install of FC5, webdav navigation (with authentication) has become
very slow. It used to be fast in FC4.
Comment 1 Ola Thoresen 2006-04-15 05:23:22 EDT
You don't happen to be using a DNS-server that does not answer to TCP-requests?

I had the same problem, and it turned out it was waiting for reply to some
unknown DNS-request using tcp (instead of udp as is normally used for DNS-requests).
The nameserver never replied to these requests, and the webdav session was
hanging, waiting for the reply.
After a simple 
 iptables -I OUTPUT -p tcp --dport 53 -j REJECT
webdav was quite usable again.
Comment 2 Marius Andreiana 2006-04-18 15:52:52 EDT
The DNS server doesn't answer to TCP requests (tested with telnet server 53)

iptables command didn't fix it for me and it shouldn't have been required, as
DNS queries should be made only on UDP (? not sure about this)
http://en.wikipedia.org/wiki/Domain_Name_System
Comment 3 oll 2006-05-19 05:26:27 EDT
I can confirm it with all my users FC5.
It makes gnome-user-share completly unusable.
Comment 4 Alexander Larsson 2006-08-09 04:39:29 EDT
I think this might be fixed in gnome vfs 2.15.91.
Comment 5 Marius Andreiana 2006-11-02 10:34:26 EST
Still not fixed in FC6. Slow = more than 20 seconds to open a folder, vs < 1 sec
in FC4.
Comment 6 Michal Babej 2006-11-23 12:21:20 EST
works fine on me, even large file transfers. The webdav server is on LAN, though.
Comment 7 Marius Andreiana 2006-11-24 02:22:45 EST
How could we debug this?

This are ping results:
... icmp_seq=4 ttl=247 time=186 ms

---  ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 186.222/186.355/186.517/0.444 ms

Thanks
Comment 8 Alexander Larsson 2006-11-24 03:27:58 EST
I don't really know. You can enable debugging in the http gnome-vfs backend if
you rebuild it with DEBUG_HTTP_ENABLE defined. That might help.

Also, if you file a bug upstream its likely that you get help faster, since they
know about their code better.
Comment 9 Marius Andreiana 2006-11-28 12:18:26 EST
Alex,

From DEBUG_HTTP_ENABLE output I can see that when a request it's made for
server.com/a/b/c/d/
do_get_file_info() (including sessions searching, propfind_result()...) will be
called for each
/a
/a/b
/a/b/c
/a/b/c/d/
for 3 times (!)  - so 12 calls in total
and then finnaly doing parsing dav: 1,2 {in parse_dav_header} and getting the
actual information. From the output of debug info after clicking on folder d in
/a/b/c :
cat dav.txt|grep "do_get_file_info {in +++}"|wc -l
14

Is this normal? Why isn't a single call enough?

I cannot provide complete output, but please let me know if something else is
needed or give me some hints on where to look next.

Thanks
Comment 10 Alexander Larsson 2006-11-29 04:01:52 EST
I dunno if it is normal or not, a nautilus operation is quite a complex thing.
However, 12 dav operations shouldn't take 20 seconds.
Comment 11 Bug Zapper 2008-04-03 22:19:16 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 12 Bug Zapper 2008-05-06 11:40:51 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.