# Verzeichnislisting mit Konqueror elend lahm

## BlackEye

Hallo!

Ich hab hier ein komisches Problem..

Auf einem Windowsrechner habe ich eine Freigabe, in der es ein Verzeichnis gibt, welches ca 1300 Dateien beinhaltet. Wenn ich diese Freigabe bei mir per cifs einmounte und mit dem konqueror auf das Verzeichnis gehe braucht der ungelogen über eine Minute bis Listing ENDLICH da ist. Gebe ich im Konqueror hingegen "smb://server/freigabe/verzeichnis" ein, ist es im Bruchteil einer Sekunde zu sehen. Wie kann das sein?

Gruß,

Martin

----------

## m.b.j.

Brauch das Listing unter der Shell genauso lange (ls -l)?

----------

## BlackEye

nein - ist mit ls so schnell wie wenn ich mit dem konqueror den kioslave smb:// benutze

geht ca innerhalb 200ms

edit: der dolphin schafft das übrigens auch sehr schnell über den normalen Verzeichnispfad. Also muss es irgendwie mit dem Konqueror zusammen hängen. Vielleicht ist es irgend eine Einstellung, die Metadaten oder sonstige Informationen aus den vielen Dateien bezieht die dann sehr lange dauert..?

----------

## m.b.j.

Meine Theorie:

Konqueror mit smb:// IO-Slave macht weniger/effizientere/zusammengefasste Tests für die einzelnen Dateien (atime,ctime usw...), während der Zugriff übers VFS für jede einzelne Dateien des listings einen Haufen einzelne stat calls usw rauswirft. Das fällt bei normalen Dateisystemen wohl nicht weiter auf (caching im speicher). Vllt baut das VFS auch für jede einzelne Datei-Metainformation eine eigene TCP Verbindung auf, oder es kann die Kommandos nicht zusammenfassen.

Kenne mich mit dem möglichkeiten des SMB Protokolls da nicht so gut aus. 

Kannst ja mal gucken ob du mit etheral weiter dahinterkommst was beim kioslave effizienter läuft?

----------

## BlackEye

Okay, Du scheinst recht zu haben...

Konqueror macht da irgendwie Mist in meinen augen

Also Anzahl Pakete mal in der Überischt:

Dolphin über mountpoint: 271 Pakete

Konqueror über IO-Slave: > 5900 Pakete

Konqueror über mountpoint: > 36000 Pakete O.o

Okay, also das ist schon recht eindeutig... Der Unterschied zwischen Dolphin per mounpoint und konqueror per IO-Slave ist wohl damit zu erklären, dass Dolphin nicht so viele Informationen über die Dateien einholt wie der Konqueror. Aber dass der Konqueror über den Mountpoint so dermaßen viele Pakete senden muss finde ich erschreckend... Das muss irgendwie effizienter gehen

----------

## m.b.j.

Das ist wohl ein Design Problem:

Während der der Zugriff über einen KIO-Slave(oder anderes) schon beim Aufruf weiß das das komplette Direktory Listing mit Statts übertragen werden soll. Also kann dafür z.b die Funktion SMBKontext.getDirlistWithCompleteStats(); aufgerufen werden. 

(ka ob die wirklich so heißt)

Anders verhält sich das VFS: Über die Posix Schnittstelle (opendir?) wird zuerst das directory handlegeöffnet, dann über die Namen der Elemente des Directorys iteriert(readdir). Bei jedem Element werden dann die statts einzeln abgefragt. Das VFS bietet imho keine getDirlistWithCompleteStats() funktion an. Also wird für jede(s) Datei/Directory im Listing der komplette Protokoll-Overhead (bei SMB schon was größer) auf die Gesamtzeit dazugerechnet. Woher soll das VFS denn auch wissen das noch 1000 Statt Request kommen, wenn es den ersten bearbeitet, um dann eventuell den effizenteren Aufruf zu nutzen...

Ich hoffe man kommt mit dem Gedankengang klar?

----------

## BlackEye

ja klar, kommt man  :Smile: 

Nun, man kann aber ganz leicht in Erfahrung bringen wieviel da noch kommt. Und wenn ich mir zuerst nur alle Dateinamen in ein Array lade und anschließend abfrage wieviele Elemente ich habe, so weiss ich doch wieviel ich zu laden habe. Das einzige was ich dann halt (ohne Weiteres) nicht weiss ist, welches Dateisystem dahinter steckt. Aber das könnte man via /proc/mounts auch noch herausfinden. Aber ich denke da hat sich noch keiner Gedanken drum gemacht, soetwas effizient zu lösen. Vielleicht sollte ich mal ein Bugreport ausfüllen?

Gruß

----------

## m.b.j.

Ich denke das für lokale Zugriffe auf die Festplatte ein solches "proaktives" Caching stattfindet.

Das heißt ein opendir gefolgt von einem readdir ließt auch direkt im Vorraus  die stats von der Platte???

Ich glaube das du den Bugreport aber nicht für Konqueror ausfüllen solltest, sondern für die CIFS Implementierum im Kernel, denn hier hapert es ja an der Performance. 

```

cd $SMB_MOUNT

time find . -exec stat {} &> /dev/null \;

```

Wenn das solange dauert wie der dirlist vom konqueror dann liegts am CIFS?!

Du kannst konqueror mal mit strace laufen lassen, dann kannst du gucken was da so lange dauert!

cu

mbj

EDIT: Natürlich auf kalten Cache testen  :Wink: 

----------

## BlackEye

 *m.b.j. wrote:*   

> 
> 
> ```
> 
> cd $SMB_MOUNT
> ...

 

Also ich habs jetzt mal mit

```
$ time find /mnt/daten/windowsshare/ -maxdepth 1 -exec stat {} &> /dev/null \;

real    0m4.537s

user    0m1.476s

sys     0m1.612s
```

... gemacht. Das maxdepth, weil ich ja die Unterverzeichnisse nicht mit einlesen wollte.. Wie Du siehst recht schnell. Konqueror braucht etwas länger *g*

```
$ time strace konqueror /mnt/daten/windowsshare/ 2>/tmp/strace

real    1m41.085s

user    0m5.196s

sys     0m1.496s
```

und ich hab das Fenster direkt nachdem das Listing erschien geschlossen. Die 1:41.00 sind leider Real  :Smile: 

Auch das strace selbst braucht nicht wesentlich länger:

```
$ time konqueror /mnt/daten/windowsshare/

real    1m14.082s

user    0m4.320s

sys     0m0.580s
```

hm.... Weiss nicht wo ich ansetzen soll... das strace-file ist 2.2MB gross und es gibt zig Abfragen der Art:

```

....

access("/mnt/daten/windowsshare/Readme.txt", R_OK) = 0

readlink("/mnt/daten/windowsshare/Readme.txt", 0xbfaef478, 999) = -1 EINVAL (Invalid argument)

lstat64("/mnt/daten/windowsshare/Readme.txt", {st_mode=S_IFREG|0772, st_size=24576, ...}) = 0

open("/mnt/daten/windowsshare/Readme.txt", O_RDONLY|O_LARGEFILE) = 15

read(15, "\20\22\24 \0>,\374\0\1\7\"\0\32\3\322\0\0\0L\3F\0\0\0P"..., 4000) = 4000

close(15)

....
```

Der scheint mir jede Datei zu öffnen und ein paar Bytes auszulesen (wenn ich das richtig interpretiere). Scheinbar um den Filetype zu interpretieren oder sowas?

Jedenfalls sagt mir ein 

```
strace konqueror smb://server/share/ 2>/tmp/strace3
```

das es dort nicht so ein Block von Operationen gibt. Da kann ich vergleichbares gar nicht erst ausmachen (ist ja offensichtlich auch anders mit solchen IO-Slaves)

Ich denke da müsste man sich mal Gedanken machen, wie man soetwas effizienter lösen kann.

----------

## m.b.j.

Die ersten paar Bytes von jeder Datei werden gelesen, errinnert mich an das Tool "file"...

Unter Umständen kannst du dieses Verhalten von Seiten des Konquerors abschalten?

Das Problem würde ich nun auch beim Konqueror suchen, irgendwo wird das Verhalten ja dokumentiert sein?

Ansich sollte man den Dateityp über die Dateiendung rausfinden, im Fall das man Thumnails anzeigen will dann auch nur für .jpg usw...

Ich kann mir keinen logischen Grund Vorstellen, warum der Konqueror den FileType von jeder Datei nicht über die Endungen ermittelt?

Den genauen FileType kann er sich noch immer holen, aber erst dann wenn der Nutzer die Datei auch wirklich verwendet.

Ich bin mir übrigens (fast) sicher das es an den Tonnen von open calls liegt... und nicht am der CIFS Implementation im Kernel  :Wink: 

----------

## Keepoer

Hmm,

der Konqueror stellt doch auch Bilder in Miniaturübersicht dar (ähnlich Windows-Explorer), richtig? Die Frage ist jetzt nur, ob er das auch über smb macht. Soweit ich mich erinnere, nicht. Versuch doch mal diese Vorschaufunktion (nicht nur für Bilder) komplett zu deaktivieren. Ich bin zwar nicht wirklich sicher, dass das was bringt, aber n Versuch ist es ja wert  :Wink: 

MfG

Keep

----------

## manuels

Die Protokolle bei denen eine Vorschau erstellt werden soll kann man unter Konqueror-Einrichten -> Vorschau & Metadaten einstellen

----------

## BlackEye

Moin Leute,

also diese Vorschauoption war bei mir ohnehin nur für das lokale Dateisystem "file" eingestellt. Ich hab sie aber dennoch mal deaktiviert. Sie ist nun also wirklich komplett abgeschaltet. Auch unter "Verhalten" sind alle Optionen deaktiviert (Dateiinfos anzeigen usw..) und dennoch ist das Laufzeitverhalten dasselbe.

Ich gehe einfach mal davon aus, dass es an der Natur des Konqueror liegt. Sich von jeder Datei ein paar Bytes zu holen und den Dateitypen zu erraten mag im lokalen Dateisystem noch funktionieren, aber über remote-Filesystem ist das der Overkill schlechthin.

 *m.b.j. wrote:*   

> 
> 
> Ansich sollte man den Dateityp über die Dateiendung rausfinden, im Fall das man Thumnails anzeigen will dann auch nur für .jpg usw... 
> 
> Ich kann mir keinen logischen Grund Vorstellen, warum der Konqueror den FileType von jeder Datei nicht über die Endungen ermittelt? 
> ...

 

Ich glaube der Ursprungsgedanke bei Linux war schon immer, dass es keine Dateiendungen gibt. Das ist eine von Windows überlieferte Denkweise. Ausführbaren Dateien haben auch keine Endung und werden nur durch ihr execution-Bit identifiziert. Es gibt sogar noch einige Anwendungen die gar keine Endungen speichern wenn Du sie nicht explizit mit in den Dateinamen schreibst. Das fand ich schon immer seltsam bei Linux, aber früher war das halt so. Und aus diesem überlieferten Relikt ist das vielleicht noch eine Eigenschaft des Konqueror, dass er den Filetyp anhand von seinen Kopfdaten identifiziert und nicht anhand seiner Endung. Das ist die einzige Erklärung, die ich mir daraus reimen kann.

Aber leider hab ich auch noch nirgends eine Option dafür gefunden dies an-/abzuschalten.

btw: Ich habe einen Bugreport für den Konqueror erstellt. Mal sehen was passiert -> http://bugs.kde.org/show_bug.cgi?id=148643

Gruß,

Martin

----------

## franzf

Ich hab hier evtl. nen Tip, der das Verhalten etwas verbessern kann:

http://de.gentoo-wiki.com/Fast_Konqueror

Bei Webseiten funktioniert der DNS-Cache wunderbar, ich nehme an bei dir wird es auch zu einer deutlichen Beschleunigung kommen.

Ist halt nur ein Workaround, aber besser als nix ist es allemal  :Wink: 

(Am besten wärs wenn du momentan einfach Dolphin verwendest, der ja dieses Verhalten scheinbar nicht zeigt...)

Grüße

Franz

----------

## BlackEye

Dank Dir für den Tipp, aber ich habe einen lokalen Bind im Netzwerk laufen und daher denke ich wird dieses Problem nicht auf mich zutreffen. Ich denke eher, dass der Overhead duch das Laden der Kopfdaten diese Wartezeiten verursacht.

 *franzf wrote:*   

> Am besten wärs wenn du momentan einfach Dolphin verwendest, der ja dieses Verhalten scheinbar nicht zeigt...

 

Würde ich gern, aber der Dolphin hat keine Einstellung (zumindest hab ich sie noch nicht gefunden) für ein vernünftiges Dateibrowsing obwohl er angeblich dafür geschaffen ist. Zum vernünftigen Arbeiten möchte ich einen Dateibrowser, der mir linke Hand ein Verzeichnisbaum anzeigt und rechts den Inhalt des angeklickten Verzeichnisses. Ganz das "gewöhnliche" Verhalten also. Geht aber nicht bei dem Teil und ist daher IMHO nicht für sinnvolles Arbeiten brauchbar. Vielleicht (hoffentlich) ist das in KDE4 anders!

----------

