staging.inyokaproject.org

SMBNetFS hat Ähnlichkeiten mit FuseSMB, unterscheidet sich aber von diesem in einigen wesentlichen Punkten.

Es waere schoen, wenn diese Unterschiede auch benannt wuerden und nicht so einfach im Raum stehen bleiben wuerden... alternativ koennte ein Link auf das Ende des Artikels nicht schaden ☺

Gibt es eine Empfehlung, ab welcher Version das Programm praktisch einsetzbar ist? Obwohl es ja schon laenger in den Paketquellen enthalten ist, habe ich Skrupel, ein unter Ubuntu 8.04 funktionierendes FuseSMB mit SMBNetFS zu ersetzen... Und so schlecht sind meine Erfahrungen mit FuseSMB unter juengeren Ubuntu-Versionen auch nicht - wenn man die Option -s beruecksichtigt.

Was aber ausschlaggebend sein koennte: die Datentransferrate (die ich nie gemessen habe). Gibt es dazu konkrete Zahlen?

@aasche:

SMBNetFS hat Ähnlichkeiten mit FuseSMB, unterscheidet sich aber von diesem in einigen wesentlichen Punkten.

Es waere schoen, wenn diese Unterschiede auch benannt wuerden und nicht so einfach im Raum stehen bleiben wuerden...

Ja. Doch ich glaube, das gehört eher in den Artikel Samba Client FuseSMB. Denn FuesSMB ist das kompliziertere Tool mit mehr Einstellungs- und Individualisierungs-Möglichkeiten. Es ist aber nicht sinnvoll, bei dem einfacheren Programm auf all die zusätzlichen Features hinzuweisen, die ein anderes Programm bietet.

habe ich Skrupel, ein unter Ubuntu 8.04 funktionierendes FuseSMB mit SMBNetFS zu ersetzen...

Warum auch? SMBNetFS ist die einfachere Alternative, mit der man nicht viel falsch machen kann (was man ja vonn FuseSMB leider nicht sagen kann). Wenn FuseSMB sicher läuft, wozu etwas ändern?

Was aber ausschlaggebend sein koennte: die Datentransferrate (die ich nie gemessen habe).

Habe ich auch nicht gemessen. Da aber beide Programme auf FUSE basieren, nehme ich an, dass es da wohl keine großen Unterschiede gibt.

Fazit: SMBNetFS ist kein Ersatz für FuseSMB, sondern eine einfachere Alternative. FuseSMB ist auch bei Lucid nach wie vor in den Paketen.

Gruß - Max-Ulrich

EDIT:

@aasche:

Ich habe jetzt in den Artikeln Samba, Samba Client FuseSMB und Samba Client SMBNetFS Anmerkungen eingefügt, um die Tools "FuseSMB" und "SMBNetFS" gegeneinander abzugrenzen. Ist es so recht?

@noisefloor: Vergiss bitte nicht, den Slash noch aus dem Artikelnamen herauszunehmen, sonst laufen die Links ins Leere. Ein Redirect von "Samba Client/SMBNetFS" und von *SMBNetFS" auf Samba Client SMBNetFS wäre aber vielleicht trotzdem kein Fehler.

Max-Ulrich Farber schrieb:

@aasche: Ich habe jetzt in den Artikeln Samba, Samba Client FuseSMB und Samba Client SMBNetFS Anmerkungen eingefügt, um die Tools "FuseSMB" und "SMBNetFS" gegeneinander abzugrenzen. Ist es so recht?

ja ☺

Hallo,

die Slashs hatten wir ja mal alle entfernt... Habe den Artikel umbenannt: Samba Client SMBNetFS

Gruß, noisefloor

Danke!

Gruß - Max-Ulrich

Ich habe jetzt mal zum Testen SMBNetFS auf einer VM (Virtualbox) mit Xubuntu 11.10 Oneiric installiert. Alles läuft scheinbar problemlos, nur ist das Programm erschreckend langsam! Der Download des gleichen Dateipakets vom gleichen Server dauert mit SMBNetFS ungefähr fünf mal so lang wie direkt mit dem gvfs!!

Hat jemand ähnliche Beobachtungen gemacht oder weiß jemand, woran dies liegen könnte?

Gruß - Max-Ulrich

EDIT: Die Namensauflösung ist es nicht; ein Eintrag des Servers in /etc/hosts bringt nichts.

Gruß - Max-Ulrich

Ich habe smbnetfs unter 20.04 getestet. Grundsätzlich scheint es bislang bei mir allerdings nur zu funktionieren, wenn man die unsichere Protokollvariante 1 von cifs (für das Browsen) nimmt. Mein Vorschlag wäre daher, den Artikel zu archivieren.

Nun, damit ist SMBnetfs ja nicht allein. Auch im unverzichtbaren smbclient funktioniert das Browsen ja auch nur, wenn auf dem Server SMBv1 zugelassen ist.

Wichtig scheinen mir folgende Fragen zu sein, die ich jetzt aber leider nicht beantworten kann:

• Welche SMB-Version wird nach dem Browsen für die Kommunikation verwendet? In smbclient wird z.B. korrekt die höchst mögliche Version verwendet, auch wenn SMBv1 beim Browsen zur Anwendung kam.

• Ist SMBnetfs nach wie vor im Vergleich zu anderen VFS (z.B. Gvfs oder cifs-vfs) so langsam?

Der letzte Punkt (Langsamkeit) wäre für mich ein KO-Kriterium, ebenso wie die Beschränkung auf SMBv1 für die Kommunikation nach dem Browsen. Beim Browsen ist derzeit SMBv1 leider allgemein noch unverzichtbar.

Gruß – Max-Ulrich

Für das Browsen ab SMBv2 kann man den Dienst Web Service Discovery einrichten. Der Dienst ist bislang aber nicht in den Paketquellen enthalten. Ich hatte auch schon mal überlegt, ob man den WSD ins Wiki aufnimmt, hatte es aber aufgrund den Fremdquellenstatus wieder verworfen.

Bevor wir uns jetzt unnötige Mühe machen: Ist SMBNetFs nach wie vor so schrecklich langsam (früher hatte ich ’mal gemessen ca. 5 mal langsamer als das Gvfs)? Wenn das immer noch gilt, dann kann man es eh niemand empfehlen. Dann kann der Artikel ruhig ab ins Archiv.

Im Moment kann ich nicht mal die Freigaben mit smbnetfs einhängen, um die Geschwindigkeit im Vergleich zu gvfs und mount.cifs zu messen. Woran das scheitert, erschließt sich mir nicht. Da der Artikel generell zu überarbeiten wäre (Gruppe fuse gibt es nicht mehr, etc), bin ich daher auch dafür, den Artikel zu archivieren.

Edit: Nachdem ich es doch hingekriegt habe, habe ich die Transferraten getestet (mittels rsync auf Basis einer 500 MB Testdatei). Allerdings nicht direkt im Netzwerk, sondern Server und Client auf derselben Maschine. Das Ergebnis ist recht ernüchternd:

• gvfs

    500,000,000 100%   89.64MB/s    0:00:05 (xfr#1, to-chk=0/1)

Number of files: 1 (reg: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 500,000,000 bytes
Total transferred file size: 500,000,000 bytes
Literal data: 500,000,000 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.002 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 500,122,177
Total bytes received: 168

sent 500,122,177 bytes  received 168 bytes  90,931,335.45 bytes/sec
total size is 500,000,000  speedup is 1.00

• mount.cifs

    500,000,000 100%   45.84MB/s    0:00:10 (xfr#1, to-chk=0/1)

Number of files: 1 (reg: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 500,000,000 bytes
Total transferred file size: 500,000,000 bytes
Literal data: 500,000,000 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.002 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 500,122,177
Total bytes received: 35

sent 500,122,177 bytes  received 35 bytes  43,488,888.00 bytes/sec
total size is 500,000,000  speedup is 1.00

• smbnetnfs

    500,000,000 100%    2.59MB/s    0:03:03 (xfr#1, to-chk=0/1)

Number of files: 1 (reg: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 500,000,000 bytes
Total transferred file size: 500,000,000 bytes
Literal data: 500,000,000 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 500,122,177
Total bytes received: 35

sent 500,122,177 bytes  received 35 bytes  2,710,689.50 bytes/sec
total size is 500,000,000  speedup is 1.00

Den Unterschied zwischen gvfs und mount.cifs würde ich mit dem Caching erklären. Ich würde den Artikel archivieren.

Danke für die Mühe!

SMBNetFS: 2,59 MB/s – indiskutabel!! ☹

Ich würde den Artikel archivieren.

Absolut!

Dass das GVfs ca. um einen Faktor 2 schneller ist als das cifs-vfs ist bei mir auch ähnlich. Dafür unterstützt das cifs-vfs halt ein paar Features mehr.

Ich hatte auch schon mal überlegt, ob man den WSD ins Wiki aufnimmt, hatte es aber aufgrund den Fremdquellenstatus wieder verworfen.

Wenn der Dienst sicher läuft, warum nicht? Es wäre ja nicht die einzige Fremdquelle im Wiki…

Selbst wenn man die Performance noch steigern könnte, das Niveau via gvfs oder via mount.cifs wird meiner Meinung nach nicht annähernd erreicht werden können.

Fazit: bitte diesen Wiki Artikel archivieren.

Gruppe fuse gibt es nicht mehr, etc

Darüber habe ich mir noch gar keine Gedanken gemacht. Das hat ja auch Auswirkungen auf ein paar andere Artikel, z.B. gerade FUSE, aber auch gio, mount, gio mount und andere.

Wer könnte sich ’mal darum kümmern? Vermutlich sind meist nur kleine Korrekturen nötig, die sich ohne Baustelle machen lassen. Aber die Artikel sollten natürlich auch für die neueren Ubuntu-Versionen stimmig bleiben!

Gruß – Max-Ulrich

Jetzt ungetestet.