samba und fat32

  • hallo,

    vielleicht weiß einer von euch eine Lösung:

    Ich habe auf raspbian Samba installiert.
    Soweit alles gut... es funktioniert wenn ich als usb-Festplatte ein ext-System verwende. Verwende ich ein Fat32 oder NTFS ist Samba nur noch bis zu einer Größe bis ca. 600MByte zu verwenden. verwende ich eine größere Datei bei der Übertragung, bricht mein Win7-Rechner ab.
    Ich möchte es jetzt allen ersparen die smb.conf hier abzubilden. Der Standard ist immer der gleiche.
    Wenn ich ein Kopieren starte (Win7->Pi), entsteht sofort eine Datei mit dem Namen auf der Festplatte. Das geht auch mit einer relativ hohen Geschwindigkeit (14mByte/sec). Der Windows-Rechner 'Berechnet' während dieser Zeit die Restdauer. Ist die Datei dann angelegt, beginnt die Übertragung. Ist die Datei zu groß (sie überschreitet nicht die Einschränkungen von Fat32 !!!), braucht das anlegen der Datei vor dem Beginn der Übertragung so lange das der Windows-Rechner einen Fehler darstellt.
    Verwende ich EXT(234), dann wird die Datei in Sekunden (oder Bruchteilen davon ) angelegt.
    Meine Vermutung nun, das EXT die Fähigkeit hat eine Datei anzulegen (reservieren) damit dieser Bereich dann bei der Übertragung belegt werden kann. Wird als Filesystem Fat32 verwendet, muß Samba diese Datei anlegen indem diese auch komplett zur HDD übertragen wird. Auf dem kleinen Früchtchen dauert das aber zu lange.
    Ich habe jetzt schon in der Samba-docu nachgesehen ob es da Optionen gibt um dieses 'Intiale' erzeugen der Datei zu verhindern. Hier habe ich aber nichts gefunden.

    Weiß einer von euch wie man das hinbekommt das kein Timeout erzeugt wird?
    Eventuell sind das sogar Optionen beim Kernel bauen oder bei den dosutils die einfach nur aktiviert werden müssen.

  • Wenn du ein ext-fs nutzt und dann die datei via samba von windows auf das ext-fs kopierst dann funktioniert es? oder wie darf man das verstehen?
    Schon mal in die logs vom samba geschaut?

    --
    man ist das System-Anzeigeprogramm für die Handbuchseiten von Linux.

  • hallo,

    korrekt... ist am pi eine ext-platte angeschlossen, dann geht es (ich habe jetzt nur ext4 versucht, favorisiert verwendet ich xfs, das bring aber debian nicht mit).

    Ist am pi eine fat32 platte angeschlossen, dann geht das nicht mit größeren Dateien.

    in der Zwischenzeit habe ich herausgefunden das es am preallocation liegt. Abhängig von der Version des samba/clients wird das verwendet oder nicht.
    Das bedeutet das samba den Befehl erhält die Datei in der richtigen Größe zu reservieren.
    Der Sinn dahinter ist wohl um festzustellen das auf dem Laufwerk noch genügend platz ist.

    Bei den Linux-Dateisystemen geht das sehr schnell. Im Falle eines FAT32 wird die Datei erzeugt und dann gefüllt. Und genau das sorgt dann für einen Timeout weil der pi zu langsam ist.

    Jetzt muß ich nur noch rausfinden ob es für samba oder für vfat eventuell einen Patch gibt.
    Es gibt unter Samba eine Config, die aber leider das nicht abschaltet sondern dann nur auf allen Dateisystemen anwendet (mit dem Füllen)

    bye woodym

    ps.: auf diese Problem scheinen schon viele gestoßen zu sein... bisher habe ich aber keine Lösungen gefunden.

  • hallo,
    nun das Ergebnis meiner Suche:

    es wird von Samba ein ftruncate verwendet um eine Datei zu vergrößern. Das führt bei einem FAT32 zu einem auffüllen der Datei mit nullen. Das wiederum braucht so lange das es abbricht.
    Dateisysteme die ein spars-file unterstützen (z.b. xfs, ext4 usw) haben nicht das Problem.

    Das nette ist, das nur der Explorer unter Windows diese Funktion überhaupt verwendet. Greift man mit dem Mac oder Linux auf diese Sambafreigabe zu, dann wird überhaupt nicht die Methode verwendet (erst Datei anlegen mit 0 Bytes; erweitern auf die benötigte größe; Daten dort einfügen wo der platz geschaffen wurde).

    Ich hatte mehrere Argumente für dieses Vorgehen gelesen. Mein Eindruck hierzu das es ehr problematisch ist im Zeitalter der Flash-Speicher erst einen Bereich auszunullen und ihn dann zu beschreiben. Das sind dann zwei schreibzyklen statt nur einer nötigen. Flashspeicher halten dann nur halb so lange.

    Wer dennoch auf die Problematik stößt und dies unter Windows umgehen möchte, hat die Möglichkeit nicht den Explorer zum kopieren zu verwenden. Ich habe das jetzt einmal versucht mit 'Double Commander', dort hat es wunderbar funktioniert. Der Versuch mit 'Free Commander' ist gescheitert weil er die Kopierfunktionen des Explorer zu nutzen scheint.

    bye woodym

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!