laaangsame USB-Sticks an /autofs/sdb1 wegen sync als mount-Option

  • Hallo,


    32GB USB-Stick angeschlossen, per telnet
    cp -p /media/hdd/movie/XYZ.ts /autofs/sdb1/
    eingegeben und gewundert, weil der Kopiervorgang so lange dauerte. ?(


    Da wurde mit 1MB/s kopiert :cursing: Geschwindigkeiten wie USB 1.0!


    Stick an Laptop angeschlossen, Download .ts über LAN knapp 10MB/s,
    Laptop hat mit 8MB/s auf USB Stick geschrieben, zusammen 8MB/s, das ist erträglich.


    Schuld daran ist die Option sync in der Einstellung des autofs.


    # cat /proc/mounts
    /dev/sdb1 /autofs/sdb1 ext3 rw,sync,relatime,[...] 0 0


    Aus der manpage zu mount:

    Quote

    sync All I/O to the filesystem should be done synchronously. In case
    of media with limited number of write cycles (e.g. some flash
    drives) "sync" may cause life-cycle shortening.

    Ohje, sync soll also auch noch schädlich sein. :!:


    Sync heißt, dass dauernd Kleinteile geschrieben werden, wie die Anwendung sie produziert. Ohne sync sammelt und puffert das Dateisystem und schreibt große Blöcke am Stück. Das Fehlen von Sync ist verheerend. Hier ein paar Geschwindigkeitsmessungen mit einem anderen Stick:

    Code
    1. # cd /autofs/sdb1/
    2. # dd if=/dev/zero of=foo obs=1M count=200000 &
    3. 26214400 bytes (25.0MB) copied, 9.915029 seconds, 2.5MB/s
    4. # dd if=/dev/zero of=foo obs=64K count=200000 &
    5. 42270720 bytes (40.3MB) copied, 23.951959 seconds, 1.7MB/s
    6. # dd if=/dev/zero of=foo obs=4K count=200000 &
    7. 2232320 bytes (2.1MB) copied, 10.940550 seconds, 199.3KB/s
    8. # dd if=/dev/zero of=foo count=200000 & # dd default sind 512 Bytes
    9. 2978304 bytes (2.8MB) copied, 35.990534 seconds, 80.8KB/s
    10. 73465344 bytes (70.1MB) copied, 17.666410 seconds, 4.0MB/s # mit async


    Von 80KB/s(!) bis 4MB/s alles drin, je nachdem, wie ein Programm die Daten produziert. Kleinvieh macht's sehr langsam.


    Weshalb benutze ich autofs? Ich liebe die Kommandozeile und kopiere Dateien auf einen Memory-Stick nicht über eine Fernseh-GUI der Dreambox, sondern indem ich mich per telnet einlogge und /autofs/sdb1 nutze, was mir die mount+umount Befehle erspart.


    Vielleicht wurde sync bei autofs eingestellt, um das Risiko von Datenverlusten zu verringern, wenn man Geräte während oder kurz nach Schreibvorgängen entfernt. Hier überwiegen jedoch die Nachteile. Wenn ich in dmesg Zeilen wie "kjournald starting. Commit interval 5 seconds" richtig deute, schreibt der Linux-Kernel eh nach spätestens 5 Sekunden Restdaten auf die Platte. Vor 20 Jahren war bei Sun-Servern eine halbe Minute eingestellt, da war das Risiko bei Crash oder Stromausfall höher.


    Abhilfe

    • /etc/auto.hotplug editieren und sync bei /dev entfernen
      * -fstype=auto,rw,relatime :/dev/&
    • Optional in /etc/auto.master timeout verringern (3 statt 5 Sekunden, vgl. /etc/default/autofs)
      /autofs /etc/auto.hotplug --timeout=3
    • autofs neu starten (nur nötig falls auto.master nicht verändert wurde)
      # /etc/init.d/autofs restart

    Die Verringerung des Timeouts dient dazu, Restdaten spätestens 3 Sekunden nach Ende der letzten Benutzung zu schreiben. Dann entfernt autofs den mount-Eintrag und der Stick kann abgezogen werden. Ich benutze übrigens einen Stick mit Leuchtdiode.


    Seither ist die Verwendung von autofs genau so schnell, als hätte ich einen mount über die Shell oder das GUI durchgeführt! Nach drei Sekunden wird das Dateisystem abgehängt, dabei kann noch ein letzter Schreibvorgang vorkommen. Wer mag, kann df oder cat /proc/mounts ausführen und prüfen, dass /dev/sdb1 verschwunden ist. Danach kann ich den USB-Stick sicher entfernen.


    Ich würde es sehr begrüßen, wenn diese Änderung auf der Dreambox Einzug fände. :thumbsup:


    Frohes neues Jahr!

  • Und du machst dann allen usern den Filesystemcheck weil sie die stick nach dem schreiben ohne umounten abstecken oder das sync vom automatischen umount vielleicht noch läuft ?


    Sonst kannst du auch gerne wieder read only mounts haben 8)


    Insofern denke ich das es wenn es jemand so benutzen will sich das auch selber anpassen wird müssen, in den Standard wird das wohl nicht reinkommen, weil es so stabiler ist gerade wenn man nur stick anstecken und z.B. irghendwelche Bilder ansehen oder files abspielen, wofür das automounten am USB primär gedacht ist.


    Bei Netzwerkmounts ist es was anders.

  • Quote

    weil sie die stick nach dem schreiben ohne umounten abstecken

    Das mache ich doch auch, das ist der ganze Witz bei autofs.

    Quote

    oder das sync vom automatischen umount vielleicht noch läuft ?

    Ich meine nach wie vor, dass die Vorteile überwiegen. Ich glaube, wir brauchen nur über den richtigen Timeout streiten, damit der Timeout eintrifft, bevor die User einen Stick abziehen.


    Selbst --timeout=1 also 1 Sekunde wäre noch um Welten besser als jeder mount mit sync. Ohne "sync" kann das FS alles zusammenfassen, was binnen dieser Sekunde an write() gekommen ist. Selbst beim Befehl cp ist das eine Menge.


    Der Unterschied zwischen 1MB/s und 8MB/s entscheidet über die Benutzbarkeit eines Sticks. Niemand will mit 1MB/s Videos kopieren. Als ich diese lahme Übertragung sah, dachte ich schon, an der Dreambox wäre etwas faul.


    Bei ext3 wäre noch die Mount-Option commit=1 (ebenfalls 1 Sekunde statt der üblichen 5) deutlich performanter als die Option sync, und kaum weniger Zuverlässig beim typischen Abziehen eines Sticks, würde ich vermuten.


    Ich würde erwarten, dass ein OS sinnvoll mit Resourcen umgeht. :D sync ist kein sinnvoller Umgang mit Flash-Speichern.

  • Nochmals, das autofs mounten von USB sticks ist primär zum Abspielen und nicht um dann was drauf zu schreiben. WENN du was schreiben willst hänge den stick ordentlich ein und staune welche sync option da verwendet wird :-)


    Ich weis schon das es attraktiv ist schnell anzustecken, zu schreiben und ohne Rücksicht/umount wieder abzustecken, aber das macht eben nicht bei jedem Filesystem wirklich Spass.


    Und wenn du nicht verstehst das jedes umount einen sync triggert weil alles rausgeschrieben werden muss wird es auch schwer.


    Aber wie ich dir schon geschrieben habe wird das DMM entscheiden müssen und nicht wir, ich habe dir nur versucht zu erklären warum sie es wahrscheinlich nicht ändern werden :-)


    Und formatiere mal wenn es sich um FAT handelt mit größerer Blockgröße und erkenne den Unterschied.