[Gelöst] Freetz-Samba 3.6.4 - Schreiben startet verzögert bzw. startet gar nicht

SaschaBr

Aktives Mitglied
Mitglied seit
1 Mai 2007
Beiträge
2,350
Punkte für Reaktionen
32
Punkte
48
Hallo Leute.

Ich hätte da mal ein Problem:
Wenn ich Dateien vom Windows-Rechner (in diesem Fall XP-SP3) auf den Freetz-Samba (3.6.4) kopiere, wird der Schreibvorgang zu Beginn verzögert, je größer die Datei umso länger. Ist die Datei zu Groß (getestet mit ~2000 Megabyte), wird dies nach einer gewissen Zeit mit einer Fehlermeldung in Windows (%Datei-blablabla% kann nicht kopiert werden: Der angegebene Netzwerkname ist nicht mehr verfügbar) abgebrochen (Timeout??).

Ich habe beobachtet, dass Samba wohl erst die Datei in voller Länge anlegt, und erst dann das eigentliche Kopieren startet.

Ich habe schon das halbe Internet (und natürlich auch diese Forum) abgegrast, aber bisher keine Lösung gefunden, habe aber wahrscheinlich nur die falschen Suchbegriffe. Ich konnte bisher auch nicht herausfinden, ob dies ein Freetz-spezifisches Problem ist, oder ob das normal für Samba ist.

Hat das auch schon jemand beobachtet? Weiß einer vieleicht, mit welcher Option ich dieses "Erst anlegen, dann transferieren" deaktivieren kann? Oder zumindest wonach ich suchen kann?


Samba: Experten Optionen
Code:
Socket options = TCP_NODELAY IPTOS_LOWDELAY
read raw = yes
write raw = yes
oplocks = no
max xmit = 65535
dead time = 15
getwd cache = yes
unix charset = UTF-8
 
Zuletzt bearbeitet:
Also ich habe Samba 3.6.3 noch drauf und ich kann kein solches Verhalten feststellen. Transfers auch wenn sie 700MB groß sind starten augenblicklich. Ich verwende allerdings Windows 7 und nicht dieses... nunja ;-). Windows 7 verwendet auch eine neuere Protokollversion von Samba (SMB2). Weiß nicht ob es daran liegt. Welches Dateisystem verwendest du Serverseitig ? Bei mir ist es ext3
Expert:
Code:
name resolve order = wins lmhosts hosts bcast
max protocol = SMB2
wins support = yes
local master = yes
domain master = yes
preferred master = yes
 
Ja, ich weiß, aber auf dem Lappi läuft halt noch XP. Aber auf meiner großen, nicht klappbaren Kiste läuft auch Windows 7. Guter Tipp, werde ich im Laufe der Woche mal testen (wenn er wieder angeklemmt ist).
Serverseitig verwende ich fat32. Könnte das echt daran liegen?? Bis vor ca. zwei Monaten hatte ich auch noch eine Platte mit ext2 drann, beim Tausch der Festplatte auf ein größeres Modell habe ich mich (der einfachheit-halber) für fat32 entschieden.

Na, jetzt habe ich schonmal zwei Ansätze:
Win XP vs. Win 7
fat32 vs. ext2

Danke dafür.
 
Da SMB2 zwar schon "Stable" ist aber noch aus Sicherheitsgründen default off musst du wenn du es testen willst in die Konfiguration
Code:
max protocol = SMB2
einfügen
 
Hatte exakt das gleiche Problem mit Samba 3.6.3, auch mit XP als Gegenstelle. Filesystem auf der Box ist völlig egal, SMB oder SMB2 macht auch keinen Unterschied. Ich musste wieder zurück auf 3.0.x, da alles Probieren bei mir den von dir beschriebenen Effekt nicht beseitigt hat. Würde ich an deiner Stelle auch in Erwägung ziehen, falls du nicht viel Zeit vergeuden willst.
 
Ich habe beobachtet, dass Samba wohl erst die Datei in voller Länge anlegt, und erst dann das eigentliche Kopieren startet.
Hast Du vielleicht strict allocate aktiviert?

Ansonsten übersetze mal Samba mit FREETZ_PACKAGE_SAMBA_MAX_DEBUG_LEVEL=1000 und schau, was beim Abbruch in syslog steht.

Edit: Und ich meine das Problem ist nicht freetz spezifisch, s. google
 
Zuletzt bearbeitet:
Ich habe diese Nacht meine Festplatte von FAT32 nach ext2 umgestellt (Daten gesichert, mit PartedMagic in ext2 formatiert, Daten zurück geschrieben).
Jetzt grade ein schneller Test mit dem 2000 Megabyte-File: Schreiben wird sofort und ohne Verzögerung gestartet!

Als Suchiman gestern die Frage nach dem serverseitigem Dateisystem stellte, wars mir eigentlich schon klar. Das war (neben der Samba-Version 3.6) die einzige große Veränderung.

@make: An der Samba-Version alleine scheint es also auch nicht zu liegen (eventuell aber in Kombination mit FAT32 ?).

@er13: Nein, habe ich nicht (siehe Experten Optionen im Eröffnungspost). Ist das eventuell nur für FAT32 auf yes? Wie gesagt, mit ext2 hat das Schreiben eben sofort gestartet, muss das aber noch ausgiebig testen.
 
Beim Kopieren mit dem Windows Explorer (zumindest ältere Versionen) wird die Datei sofort in voller Länge angelegt. Erst danach wird der Inhalt gefüllt. Dies hat den Vorteil, dass bei zu wenig Platz auf der Platte der Fehler sofort auftritt und nicht erst nach längerem Kopieren.

Dieses Anlegen in voller Länge geht aber nur auf FAT (und evtl. NTFS). FAT unterstützt keine "Löcher" in einer Datei, ein Schreiben weiter hinten bewirkt automatisch, das alle Blöcke bis zu der Stelle belegt werden. Bei EXT2 oder allgemein allen UNIX-basierten Dateisystemen wird aber beim Schreiben hinter dem Dateiende nur ein Block für diese Position belegt und nicht für alle Blöcke bis zu dieser Stelle.

Die Option "strict allocate" emuliert das Verhalten des FAT Dateisystems auf UNIX Dateisystemen. Diese Option zu aktivieren wäre also keine Lösung für das ursprüngliche Problem, sondern sondern eher eine Ursache dafür, bzw. würde bewirken, dass das gleiche Problem auch mit einem UNIX Dateisystem auftreten kann. Bei FAT ist also nicht "strict allocate" auf yes, sondern FAT Dateisystem verhält sich zwangsläufig so, ohne dass das Programm etwas spezielles dafür tun muss oder es vermeiden könnte.
 
Hmm, seltsam. Ich habe auf meinem Stick ext2 als Datengrab und vfat für logfiles und war mir sicher, das Problem bei beiden Partitionen beobachtet zu haben. Große Dateien sind bei fat ja ohnehin nur begrenzt möglich.

Aber egal ... Wenn es bei dir mit ext2/3 funktioniert dann entschuldige bitte meinen in die Irre führenden Ratschlag.
 
Beim Kopieren mit dem Windows Explorer (zumindest ältere Versionen) wird die Datei sofort in voller Länge angelegt. Erst danach wird der Inhalt gefüllt. ...

Und wieder was gelernt, danke Ralf.

@make:
Macht ja nix, hätte auch sein können, und wäre der nächste logische Schritt gewesen (Samba 3.0.x).

@all:
Für mich ist das Problem (welches ja scheinbar Feature ist) mit ext2 jedenfalls behoben. Danke für die Hilfe, auch wenn es nicht ganz ein "Freetz-Thema" war.


Ich denke, hier kann ein Schloss drauf.
 
Zuletzt bearbeitet:
Nicht ganz Freetz spezifisch, aber aufgrund der Hardware dauert diese Operation auf einer Fritz Box deutlich länger als auf einem PC. Zum einen ist die CPU nicht die schnellste, und zum anderen die Übertragungsgeschwindigkeit am USB auch nicht. Eine moderne Platte schafft schon mal 30-100 MB/s, da braucht man schon sehr große Dateien, um einen Timeout zu provozieren.
 

Neueste Beiträge

Statistik des Forums

Themen
244,691
Beiträge
2,216,605
Mitglieder
371,308
Neuestes Mitglied
Chrischan 79
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.