[e1] Geschwindigkeitsproblem Samba 2.8.0

[Detlef Paschke]

Hallo an alle,

nach einigem suchen habe ich den vermutlich "schuldigen" für mein
Problem gefunden.
Es geht darum, dass beim Kopieren auf einen Hardware Raid-5 Verbund
einige Sekunden Vergehen bevor der Kopierprozess Startet. Wenn mehrere
Dateien auf ein mal Kopiert werden wird vor jeder Datei eine solche
"Pause" eingelegt die je nach Dateigröße ca. 10 Sek. dauert. Beim lesen
vom Raid-5 gibt es eine solche Verzögerung nicht. Ich hatte bereits die
Vermutung, dass es mit samba_vscan zusammenhängen kann aber das hatte
ich nie bewusst aktiviert und aktuell ist es wohl auch gar nicht mehr
vorhanden wenn ich es richtig gelesen habe.
Um ein Problem mit der Hardware auszuschließen habe ich einmal Lokal und
auch per ftp Dateien auf den Raid-5 Kopiert und dabei eine solche
Verzögerung nicht beobachten können. Ich bin zwar etwas Update-faul aber
so lange kann dieses Verhalten noch nicht existieren.
Hat da jemand einen Lösungsansatz.

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Detlef Paschke
Es geht darum, dass beim Kopieren auf einen Hardware Raid-5 Verbund
einige Sekunden Vergehen bevor der Kopierprozess Startet. Wenn mehrere
Dateien auf ein mal Kopiert werden wird vor jeder Datei eine solche
"Pause" eingelegt die je nach Dateigröße ca. 10 Sek. dauert. Beim lesen

Kann ich (ohne Raid5) natürlich nicht nachvollziehen.

Post by Detlef Paschke
vom Raid-5 gibt es eine solche Verzögerung nicht. Ich hatte bereits die
Vermutung, dass es mit samba_vscan zusammenhängen kann aber das hatte
ich nie bewusst aktiviert und aktuell ist es wohl auch gar nicht mehr
vorhanden wenn ich es richtig gelesen habe.

Es gibt kein samba_vscan für die neueren Samba-Versionen mehr.

Post by Detlef Paschke
Um ein Problem mit der Hardware auszuschließen habe ich einmal Lokal und
auch per ftp Dateien auf den Raid-5 Kopiert und dabei eine solche
Verzögerung nicht beobachten können. Ich bin zwar etwas Update-faul aber
so lange kann dieses Verhalten noch nicht existieren.
Hat da jemand einen Lösungsansatz.

Das Übliche:

Rechner direkt miteinander verbinden (um Hubs/Switches/Verkabelung/...
auszuschalten). Virenscanner auf Client und Server deaktivieren. Testen.

Irgendwelche von Hand gesetzten Spezialitäten in der smb.conf?

Standard:
alsa # testparm -sv 2>/dev/null | grep 'socket options'
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE

Ändert sich etwas, wenn Du das Protokoll auf das alte NT1 festnagelst?

Standard:
alsa # testparm -sv 2>/dev/null | grep 'max protocol'
server max protocol = SMB3
client max protocol = SMB3
alsa # grep 'max protocol' /etc/smb.conf
max protocol = SMB3
client max protocol = SMB3

Setze testweise in smb.conf

max protocol = NT1

, starte Samba neu, reboote den Client und teste. Dito mit

max protocol = SMB2

Aber _eigentlich_ sollte Win7 mit 'max protocol = SMB3' (es wird dabei
von Samba mit Win7/Windows 2008R2 SMB2.1 ausgehandelt, mit Win8/Windows
Server 2012 SMB2.2/SMB3, mit Win8.1/Windows Server 2012 R2 SMB3.02 [von
Samba bisher noch nicht unterstützt]) _viel_ schneller sein, da es damit
viele asynchrone Requests an Samba absetzt, welches diese parallel
verarbeitet.

Aber man weiß ja nie, vielleicht schlummert da ja irgendwo noch ein Bug...

https://wiki.samba.org/index.php/Samba3/SMB2
https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html
(suche beim letzten Link nach 'server max protocol')

[Detlef Paschke]

Am 19.12.2014 um 21:49 schrieb Thomas Bork:

Hallo Thomas,

Post by Thomas Bork
Rechner direkt miteinander verbinden (um Hubs/Switches/Verkabelung/...
auszuschalten). Virenscanner auf Client und Server deaktivieren. Testen.

habe ich gemacht, hat aber keinerlei Änderungen gebracht. Je nach
Dateigröße dauert es mehrere Sekunden bis der Fortschrittsbalken, die
anzeige der Datenrate und die Anzeige der bereits Kopierten Datenmenge
eine Anzeige bringt.

Post by Thomas Bork
Irgendwelche von Hand gesetzten Spezialitäten in der smb.conf?
alsa # testparm -sv 2>/dev/null | grep 'socket options'
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE
Ändert sich etwas, wenn Du das Protokoll auf das alte NT1 festnagelst?
alsa # testparm -sv 2>/dev/null | grep 'max protocol'
server max protocol = SMB3
client max protocol = SMB3
alsa # grep 'max protocol' /etc/smb.conf
max protocol = SMB3
client max protocol = SMB3
Setze testweise in smb.conf
max protocol = NT1
, starte Samba neu, reboote den Client und teste. Dito mit
max protocol = SMB2

Steht und stand bei mir alles auf Standard-Einstellungen und die
Änderung auf NT1 bzw. SMB2 hat auch nichts gebracht.

Post by Thomas Bork
Aber man weiß ja nie, vielleicht schlummert da ja irgendwo noch ein Bug...

Ich habe auch noch einmal den Controller getauscht (bei Hardware-Raid
sollte man ja immer einen Ersatz haben) aber auch das hat nichts
geändert. Was mir aber aufgefallen ist, die Controller- und die
Festplatten-LED's flimmern auch dann "lustig" vor sich her wenn das
Kopieren gerade gestartet wurde aber eben eine solche Pause gemacht wird.
Darauf hin habe ich den guten alten Servant Salamander rausgekramt und
dort startet der Fortschrittsbalken sofort, der Salamander ist halt von
hause aus recht träge beim Kopieren. Diesen komischen Windows-Explorer
kann man dafür nicht heranziehen da er ja keinen wirklichen
Fortschrittsbalken hat. Ich muss also davon ausgehen, dass mein
bevorzugter Dateimanager (Total-Commander) für diese Pause
verantwortlich ist.

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Detlef Paschke
Fortschrittsbalken hat. Ich muss also davon ausgehen, dass mein
bevorzugter Dateimanager (Total-Commander) für diese Pause
verantwortlich ist.

Aus dem Changelog:

2.7.0 --> 2.7.1
---------------
- 4.1.13 (4.1.13-for-eisfair-X-patch-1, status testing)
- patches for function daemon_ready
- /var/install/config.d/samba.sh:
setting 'strict allocate = yes',
see https://wiki.samba.org/index.php/Linux_Performance

Du könntest also auch mal

'strict allocate = yes'

in der smb.conf auskommentieren, Samba neu starten und testen. Eventuell
wirkt sich das bei Raids negativ aus. Lese aber unbedingt unter dem oben
angegebenen Link nach.

[Detlef Paschke]

Am 20.12.2014 um 19:44 schrieb Thomas Bork:

Hallo Thomas,

Post by Thomas Bork
Du könntest also auch mal
'strict allocate = yes'
in der smb.conf auskommentieren, Samba neu starten und testen. Eventuell
wirkt sich das bei Raids negativ aus. Lese aber unbedingt unter dem oben
angegebenen Link nach.

das scheint dieses Problemchen in der Tat zu beheben. Ich muss gestehen,
dass ich bei wiki.samba.org von diesem Thema nicht viel verstanden habe.
Das liegt nicht zuletzt sicher auch daran, dass mein Englisch nur sehr
eingeschränkt zu gebrauchen ist und die Übersetzung mit z.B. Bing bei
solchen eher fachlich/technischen Seiten nicht viele sinnvolle
Ergebnisse liefert.
Ich müsste nun aber bei jedem Update bzw. bei einer Änderung in der
Config diese Zeile immer wieder erneut Auskommentieren.?

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Detlef Paschke
das scheint dieses Problemchen in der Tat zu beheben. Ich muss gestehen,
dass ich bei wiki.samba.org von diesem Thema nicht viel verstanden habe.
Das liegt nicht zuletzt sicher auch daran, dass mein Englisch nur sehr
eingeschränkt zu gebrauchen ist und die Übersetzung mit z.B. Bing bei
solchen eher fachlich/technischen Seiten nicht viele sinnvolle
Ergebnisse liefert.

Simpel gesagt gibt es 2 Strategien, die Dateien zu schreiben. Die eine
belegt den Platz in Häppchen (allocation size/block size), die andere
auf einmal.

Bisher arbeitete unser Samba wie die erste, Windows wie die zweite. Mit

'strict allocate = yes'

arbeitet unser Samba wie Windows. Das hat den Vorteil, dass die Dateien
bei einem System mit hoher Last auf den Blockgeräten (es werden auch
viele andere Dateien zur selben Zeit über andere Prozesse gespeichert)
nicht mehr fragmentiert geschrieben werden und erhöht die
Lese-Geschwindigkeit, verlangsamt aber die Schreib-Geschwindigkeit.

Bei einem modernen Datei-System wie ext4 oder XFS ist der
Geschwindigkeits-Nachteil beim Schreiben aufgrund von extends zu
vernachlässigen. Datei-System wie ext2/ext3 unterstützen extends nicht.

Post by Detlef Paschke
Ich müsste nun aber bei jedem Update bzw. bei einer Änderung in der
Config diese Zeile immer wieder erneut Auskommentieren.?

Sollten sich noch mehr User beschweren, werde ich die Änderung wieder
zurück nehmen müssen.

[Detlef Paschke]

Am 21.12.2014 um 14:20 schrieb Thomas Bork:

Hallo Thomas,

Post by Thomas Bork
Sollten sich noch mehr User beschweren, werde ich die Änderung wieder
zurück nehmen müssen.

naja, beschweren will ich es nicht nennen es ist mir nur aufgefallen und
gleich noch als Antwort auf deine Frage in dem anderen Beitrag. Ich habe
mich erst jetzt gemeldet weil ich die Pferde nicht Scheu machen wollte.
Ich habe vor kurzem den Raid-Controller gegen einen Baugleichen
getauscht da der alte ein paar Probleme machte. Einige Zeit danach ist
mir die Sache mit den Pausen beim Kopieren erstmals aufgefallen und ich
habe natürlich zunächst den Controller im Verdacht gehabt. Nachdem ich
aber Konfiguration und Firmwareversion noch einmal verglichen habe und
Beides identisch war und zudem dieses Verhalten auch mit einem weiteren
Controller unverändert war richtete sich mein Augenmerk auf das System.
Um Netzwerkprobleme ausschließen zu können habe ich einmal Lokal Kopiert
was keinerlei Probleme bereitete und danach per FTP-Verbindung was
ebenso klappte. Erst da konnte ich mit einiger Sicherheit Samba
"verdächtigen" und dadurch auch erst jetzt die Meldung.
Es gibt eben Sachen die Treten erst mit der Zeit zu Tage und nach Murphy
auch immer erst dann wenn es kein zurück mehr gibt.

Viele Grüße
Detlef Paschke

[Detlef Paschke]

Am 21.12.2014 um 15:10 schrieb Detlef Paschke:

Hallo Thomas,

Post by Detlef Paschke

Post by Thomas Bork
Sollten sich noch mehr User beschweren, werde ich die Änderung wieder
zurück nehmen müssen.

naja, beschweren will ich es nicht nennen es ist mir nur aufgefallen und
gleich noch als Antwort auf deine Frage in dem anderen Beitrag. Ich habe
mich erst jetzt gemeldet weil ich die Pferde nicht Scheu machen wollte.

ich wollte noch nach werfen, Neben dem Raid-5 habe ich noch 4 SCSI
Platten in meinem Eisfair und beim Kopieren auf diese gibt es eine
solche Verzögerung nicht. Evtl. ist diese Information von Nutzen für dich.

Viele Grüße
Detlef Paschke

[Detlef Paschke]

Hallo Thomas,

Post by Detlef Paschke

Post by Thomas Bork
Sollten sich noch mehr User beschweren, werde ich die Änderung wieder
zurück nehmen müssen.

naja, beschweren will ich es nicht nennen es ist mir nur aufgefallen und
gleich noch als Antwort auf deine Frage in dem anderen Beitrag. Ich habe
mich erst jetzt gemeldet weil ich die Pferde nicht Scheu machen wollte.

ich wollte noch nach werfen, Neben dem Raid-5 habe ich noch 4 SCSI
Platten in meinem Eisfair und beim Kopieren auf diese gibt es eine
solche Verzögerung nicht. Evtl. ist diese Information von Nutzen für dich.

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Detlef Paschke
ich wollte noch nach werfen, Neben dem Raid-5 habe ich noch 4 SCSI
Platten in meinem Eisfair und beim Kopieren auf diese gibt es eine
solche Verzögerung nicht. Evtl. ist diese Information von Nutzen für dich.

Interessant!

Erklärt allerdings nicht das Problem von Frank im Thread "Samba 2.10.0,
kopieren größerer Dateien" in s.e.d., da er für /data/video kein Raid
verwendet (für den Rest schon):

/dev/sdd1 1.8T 1.5T 303G 83% /data/video

[Detlef Paschke]

Am 21.12.2014 um 22:43 schrieb Thomas Bork:

Hallo Thomas,

Post by Thomas Bork
Erklärt allerdings nicht das Problem von Frank im Thread "Samba 2.10.0,
kopieren größerer Dateien" in s.e.d., da er für /data/video kein Raid
/dev/sdd1 1.8T 1.5T 303G 83% /data/video

ja, die Meldung von Frank habe ich auch gelesen und mittlerweile bin ich
auch bei Samba 2.10.0 "angekommen" aber das Problem, dass beim Kopieren
von größeren Dateien ein Abbruch erfolgt besteht hier weder beim Raid
noch bei den SCSI-Platten.

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Thomas Bork
Bei einem modernen Datei-System wie ext4 oder XFS ist der
Geschwindigkeits-Nachteil beim Schreiben aufgrund von extends zu
vernachlässigen. Datei-System wie ext2/ext3 unterstützen extends nicht.

Die Dinger heissen natürlich 'extents':

http://www.heise.de/open/artikel/Extents-221268.html

[Thomas Zweifel]

Hallo Thomas

Post by Thomas Bork
see https://wiki.samba.org/index.php/Linux_Performance
Du könntest also auch mal
'strict allocate = yes'
in der smb.conf auskommentieren, Samba neu starten und testen. Eventuell
wirkt sich das bei Raids negativ aus.

Laut deinem Link:
-----------------
The most efficient way to allocate file system blocks when data is to be
written into all of the file (for example, a streaming video write) is
to allocate what is called an "extent" on the file system. The requested
blocks are then laid out by the underlying file system (ext4 or XFS) in
a very efficient way which causes the actual writes to be much faster
than having to allocate them dynamically.


Und nach der smb.conf.5
-------------------
On file systems that don't support extents (most notably ext3) this can
make Samba slower. When you work with large files over >100MB on file
systems without extents you may even run into problems with clients
running into timeouts.


Wenn man das Zusammenwürfelt passt meine Beobachtung die ich mit einem
Notebook und ext3 (ohne Raid) gemacht habe, dabei war es das gleiche
Problem wie bei Frank Meyer.



Gruss Thomas

[Thomas Bork]

Post by Thomas Zweifel
Wenn man das Zusammenwürfelt passt meine Beobachtung die ich mit einem
Notebook und ext3 (ohne Raid) gemacht habe, dabei war es das gleiche
Problem wie bei Frank Meyer.

Es gibt mit Dir (warum erst jetzt?) nach mindesten 500 Installationen
erst 2 Meldungen mit einem wirklichen Problem.

[Alex Busam]

Hallo,

Eure Unterhaltung hat mich motiviert mal wieder die Performance zu
betrachten.
Von Samba Freigabe auf den Windows Desktop kopieren: 30MB/s
Vom Desktop auf die gleiche Freigabe verschieben: 80MB/s
Auf der Freigabe eine Kopie anlegen: 30MB/s
Workstation ist Windows 7, GB-LAN

Die 30 MB/s sind ok und stellen bei uns jetzt kein Problem dar.
Allerdings finde ich die Unterschiede lesend/schreibend interessant.
Mein Eis läuft auf einem Fujitsu RX300 unter ESXi 5.1 und da gibt es
noch andere beeinflussende Komponenten, u.a. Hardware-RAID10 des Datastores.

Die Messungen mit auskommentiertem strict allocate und Restart von Samba
haben ziemlich identische Werte geliefert.

Eine Frage noch nebenbei:
ist es sinnvoll alte Kernels zu löschen? Wenn ja, wie?
Ich hab noch den smp drauf, hab aber schon länger den virt aktiviert.
Außerdem den 2.6er.

Viele Grüße
Alex



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com

[Thomas Zweifel]

Hallo Thomas

Post by Thomas Bork

Post by Thomas Zweifel
Wenn man das Zusammenwürfelt passt meine Beobachtung die ich mit einem
Notebook und ext3 (ohne Raid) gemacht habe, dabei war es das gleiche
Problem wie bei Frank Meyer.

Es gibt mit Dir (warum erst jetzt?) nach mindesten 500 Installationen
erst 2 Meldungen mit einem wirklichen Problem.

Das etwas angestaubte Samba 2.4.1 das hier noch läuft hat das 'Feature'
vermutlich noch nicht. Und auf dem Testsystem habe ich momentan ext4 am
laufen, die ideale Kombination den Fehler nicht zu finden. :-(

Das mit dem Laptop war dann doch eher Zufall, kam mir irgendwie bekannt
vor, allerdings wusste ich nicht mehr wonach ich googeln musste - bis Du
die passende Option erwähnt hast.


Als Workaround wäre eine yes/no Option längerfristig gesehen besser,
statt auf die bessere Performance bei ext4 zu verzichten...

Eventuell könnte man das mittlerweilen ziemlich unnütze 'ext2 nach ext3'
konvertieren etwas auffrischen?



Gruss Thomas

[Detlef Paschke]

Am 21.12.2014 um 19:34 schrieb Thomas Zweifel:

Hallo Thomas,

Post by Thomas Zweifel
Als Workaround wäre eine yes/no Option längerfristig gesehen besser,
statt auf die bessere Performance bei ext4 zu verzichten...

das wäre auch mein Gedanke dazu gewesen, wenn Thomas Bork das auch so
sieht ist dies sicher eine Sache die ziemlich schnell realisiert ist
wenn ich so an einige Bitten aus der Vergangenheit zurückdenke.

Post by Thomas Zweifel
Eventuell könnte man das mittlerweilen ziemlich unnütze 'ext2 nach ext3'
konvertieren etwas auffrischen?

ja, vor vielen Jahren habe ich genau diesen Punkt bei meinem jetzt noch
arbeitenden Eisfair genutzt. Ein Wechsel auf ext4 würde mir sicher keine
Nachteile bringen und wenn es ebenso einfach wie damals der Wechsel auf
ext3 von sich geht gäbe es für mich keine Fragen.

Post by Thomas Zweifel
Gruss Thomas

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Thomas Zweifel
Als Workaround wäre eine yes/no Option längerfristig gesehen besser,
statt auf die bessere Performance bei ext4 zu verzichten...

Ich verzichte dankend auf einen zusätzlichen Parameter und werde es
halten, wie bisher:

eisfair-Samba soll unter allen Umständen sicher laufen und einfach
konfigurierbar bleiben, auch wenn dabei einige Dinge auf der Strecke
bleiben.

Post by Thomas Zweifel
Eventuell könnte man das mittlerweilen ziemlich unnütze 'ext2 nach ext3'
konvertieren etwas auffrischen?

Ich glaube mich zu erinnern, dass es gerade bei ext4 Dinge gibt, die bei
konvertiertem Datei-System anders laufen, als bei einem normal erstellten.

Ah ja:
by enabling the extents feature new files will be created in extents
format, but this will not convert existing files to use extents.
Non-extent files can be transparently read and written by Ext4.

https://ext4.wiki.kernel.org/index.php/Ext4_Howto

[Thomas Zweifel]

Post by Thomas Bork
Ich glaube mich zu erinnern, dass es gerade bei ext4 Dinge gibt, die bei
konvertiertem Datei-System anders laufen, als bei einem normal erstellten.
by enabling the extents feature new files will be created in extents
format, but this will not convert existing files to use extents.
Non-extent files can be transparently read and written by Ext4.
https://ext4.wiki.kernel.org/index.php/Ext4_Howto

Ich hatte nur mitbekommen, dass es möglich ist.
Wenn es nur so halbherzig umgesetzt wurde, verstehe ich, dass ihr euch
dagegen entschieden habt.


Gruss Thomas

[Holger Bruenjes]

Hallo

Post by Thomas Zweifel
Eventuell könnte man das mittlerweilen ziemlich unnütze 'ext2 nach ext3'
konvertieren etwas auffrischen?

ehmm, diese Funktion koennte komplett entfernt werden, diese
Funktion auch fur ext3 -> ext4 anzubieten hatten wir verworfen.

Holger

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork
Du könntest also auch mal
'strict allocate = yes'

Ich habe mal in meinem Schulnetz (RAID1) mit der Option gespielt (yes oder
no).

Konnte da beim Transfer auf den eisfair (Datei von >4 GB) keinen
signifikaten Unterschied sehen.

Keine Verzögerung, Stehenbleiben, Timeout oder ähnliches.

Der Flaschenhals war eher das Netzwerk selber.

Um vergleichbare Tests hinzubekommen, wären definierte Testbedingungen
sinnvoll.

Was, in welcher Größe wird von wo nach wo in welcher Netzwerkumgebung
(100MBit oder GBit) kopiert.

[Detlef Paschke]

Am 22.12.2014 um 09:31 schrieb Marcus Roeckrath:

Hallo Marcus,

Post by Marcus Roeckrath
Um vergleichbare Tests hinzubekommen, wären definierte Testbedingungen
sinnvoll.
Was, in welcher Größe wird von wo nach wo in welcher Netzwerkumgebung
(100MBit oder GBit) kopiert.

also bei mir geht es fast ausschließlich um Video-Dateien vobei nach
meinen Beobachtungen die Größe eine Untergeordnete Rolle Spielt. Bei
Dateien um die 1,5 Gb bis 2 Gb ist die Verzögerung ca. 10 Sek., bei
kleineren Dateien um die 300 Mb etwa 3 - 4 Sek.
Das Netz ist hier Vollständig auf Gbit ausgebaut.

Viele Grüße
Detlef Paschke

[Marcus Roeckrath]

Hallo Detlef,

Post by Detlef Paschke

Post by Marcus Roeckrath
Was, in welcher Größe wird von wo nach wo in welcher Netzwerkumgebung
(100MBit oder GBit) kopiert.

also bei mir geht es fast ausschließlich um Video-Dateien vobei nach
meinen Beobachtungen die Größe eine Untergeordnete Rolle Spielt. Bei
Dateien um die 1,5 Gb bis 2 Gb ist die Verzögerung ca. 10 Sek., bei
kleineren Dateien um die 300 Mb etwa 3 - 4 Sek.

Also eine Verzögerung, bis der Fortschrittsbalken im Win-Fortschrittsfenster
(oder die Details darin aufgeklappt) einen Fortschritt anzeigen.

Ich schau mir das genau mal an.

Post by Detlef Paschke
Das Netz ist hier Vollständig auf Gbit ausgebaut.

Mein Schulnetz ist zu den Arbeitsplätzen (auch mein Admin-PC) noch mit
100MBit ausgestatett, auch wenn der zentrale Switch ein GBit-Modell ist.

Von einer NAS zum eis (Raid1) bekomme ich Raten um 15 MB/sec. Vom eis zum
eis bekomme ich bei Kopiervorgängen über den Win7-Admin-Platz etwa 25
MB/sec.

[Marcus Roeckrath]

Hallo,

Post by Marcus Roeckrath
Also eine Verzögerung, bis der Fortschrittsbalken im
Win-Fortschrittsfenster (oder die Details darin aufgeklappt) einen
Fortschritt anzeigen.
Ich schau mir das genau mal an.

Ein Kopieraktion vom Win7-Client ine eine Share des eisfair-Servers startet
laut Fortschrittsanzeige des Clients sofort (strict allocate = yes).

[Thomas Bork]

Post by Marcus Roeckrath
Um vergleichbare Tests hinzubekommen, wären definierte Testbedingungen
sinnvoll.

Und vor allem die Angabe des verwendeten Datei-Systems auf dem Laufwerk
mit der Freigabe.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Marcus Roeckrath
Um vergleichbare Tests hinzubekommen, wären definierte Testbedingungen
sinnvoll.

Und vor allem die Angabe des verwendeten Datei-Systems auf dem Laufwerk
mit der Freigabe.

Bei mir war es ext4 und kann keine Unterschiede feststellen.

[Detlef Paschke]

Am 23.12.2014 um 20:39 schrieb Thomas Bork:

Hallo Thomas,

Post by Thomas Bork
Und vor allem die Angabe des verwendeten Datei-Systems auf dem Laufwerk
mit der Freigabe.

bei mit überell ext3.

Viele Grüße
Detlef Paschke

[Thomas Bork]

Post by Detlef Paschke
bei mit überell ext3.

Samba 2.10.1 ist draussen.