SSD mounten durch fstab verzögert den Start um 30 Sekunden

  • Folgendes Problem:

    Wenn ich eine SSD (SanDisk 120 GB, Modell SSD Plus) über /etc/fstab einbinde, verzögert es den Boot-Vorgang um rund 30 Sekunden. Meine fstab sieht so aus:

    Code
    proc                  /proc           proc    defaults          0       0
    PARTUUID=4cbc14ca-01  /boot           vfat    defaults          0       2
    PARTUUID=4cbc14ca-02  /               ext4    defaults,noatime  0       1
    # a swapfile is not a swap partition, no line here
    #   use  dphys-swapfile swap[on|off]  for that
    UUID=a854d948-5199-4778-8874-c98f2202a72b /media/usbplatte/ ext4 auto,nofail,exec,sync,users,rw   0   0

    dmesg bietet folgende Informationen. Dort ist die zeitliche Lücke sehr schön zu sehen:

    Nach den 39 Sekunden ist dann tatsächlich erst der Zugriff möglich sowohl per SSH als auch direkt am Desktop. Hat jemand eine Erklärung, warum das Einhängen der SSD so lang braucht? Sowohl an meinem Ubuntu-System als auch unter Windows 10 gibt es diese Verzögerungen nicht.

    Ich habe einen Workaround, aber mit dem bin ich nicht zufrieden:

    Ich setze das Mounten in der fstab auf noauto

    Ich schreibe einen klassischen mount-Befehl in die /etc/rc.local

    Code
    mount -t ext4 /dev/sda1 /media/usbplatte &

    Dies führt dann immerhin zu einem unverzögerten Boot-Vorgang (ca. 12 Sekunden bis Desktop), weil ich den mount-Befehl in den Hintergrund schicke. Dennoch steht das Laufwerk erst nach weiteren rund 20 Sekunden zur Verfügung. Bin für jeden Tipp dankbar, der das "ordentliche" Einhängen per fstab ohne Bremse ermöglicht!

  • SSD mounten durch fstab verzögert den Start um 30 Sekunden? Schau mal ob du hier fündig wirst!

  • Nimm mal syncaus den Optionen raus!

    hyle

    Das war's! Danke!

    Der zweite Tipp (default,users,nofail) führt wieder zur Verzögerung insofern, dass der Bootvorgang selbst zwar zügig läuft, aber das Laufwerk eben doch erst nach 20 Sekunden zur Verfügung steht. Ist sync vielleicht Bestandteil von default?

    Edit: Im Nachhinein habe ich festgestellt, dass auch beim Weglassen von sync das Booten zwar zügig läuft aber die SSD trotzdem erst nach den üblichen weiteren 20 Sekunden zur Verfügung steht.

    Einmal editiert, zuletzt von JoergZ (21. September 2019 um 16:08) aus folgendem Grund: Korrektur

  • Ist sync vielleicht Bestandteil von default?

    Die default Werte sind: "rw, suid, dev, exec, auto, nouser, async". So stehts zumindest in meiner < man mount > in den "FILESYSTEM-INDEPENDENT MOUNT OPTIONS"

    Möglicherweise ist aber auch das Ext4 Filesystem auf der SSD korrupt, weil Du kein fsck auf die SSD beim Booten ausführst (in fstab steht zumindest "0"),

    Servus !

    RTFM = Read The Factory Manual, oder so

  • RTFM Welch schöner Benutzername. Hast natürlich recht. Leider haben deine Vorschläge auch keinerlei Veränderung (z. B. 2 statt 0) gebracht. Ich habe die SSD sogar neu partitioniert und ein neues EXT4-Filsystem aufgespielt, direkt vom Raspi aus. Keine Veränderung! Erst nach 34,849 ist der Boot-Prozess zu Ende und ab da ist der Zugriff auf die SSD möglich. Ich hab's noch mal mit meinem Ubuntu-System gegen gecheckt. Dort ist die SSD nach 5 Sekunden "erkannt" und nach weiteren 7 Sekunden ist das Dateisystem (gesamt nach 12 Sek.) eingehängt. Wenn die SSD am Raspi hängt blinken in der Startzeit von 34 Sekunden zwei LED am USB/SATA-Adapter. Hat der Raspi4 zu wenig Strom auf den USB-Schnittstellen? Meine Stromversorgung ist ein Original 3B-Netzteil. Das müsste doch reichen, oder?

  • daxb Ich habe mal deinen Ansatz verfolgt. Er schien Erfolg versprechend. Das manuelle mounten ging unverzüglich von statt. Allerdings hatte ich dabei zunächst übersehen, dass das System zu dem Zeitpunkt schon ca. 36 Sekunden gelaufen hat. In einem zweiten Versuch habe ich dann unmittelbar nach dem SSH-Login den mount-Befehl aus dem Terminal-Buffer abgerufen und suhe da - es dauerte und dauerte und dauerte bis diese rund eine halbe Minute vorbei ist, erst dann gelingt das mounten.

    Darauf hin habe ich mir die dmesg-Meldungen angeschaut und zwar unmittelbar nach dem Zugriff auf das System. Folgende Meldung erscheint unverändert, auch wenn man mehrmals denselben Befehl abschickt:

    Code
    pi@raspi4G:~ $ dmesg | grep sda
    [    2.575636] sd 0:0:0:0: [sda] 234455040 512-byte logical blocks: (120 GB/112 GiB)
    [    2.583174] sd 0:0:0:0: [sda] 4096-byte physical blocks
    [    2.588596] sd 0:0:0:0: [sda] Write Protect is off
    [    2.593436] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
    [    2.593789] sd 0:0:0:0: [sda] Disabling FUA
    [    2.597989] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [    2.607935] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
    [    2.624801]  sda: sda1
    [    2.629624] sd 0:0:0:0: [sda] Attached SCSI disk

    Wie gesagt, ungefähr 10 Mal den Befehl immer wieder abgeschickt und dann plötzlich dies:

    Erst dann ist das (manuelle) mounten möglich. Es ist also egal, ob ich in der fstab den Mount-Befehl schreibe oder später manuell einhänge: Es geht frühestens nach den rund 36 Sekunden. Kann diese Zeile dafür verantwortlich sein:

    Code
    [    2.607923] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)

    Andererseits: Danach wird die Partition sda1 erkannt....

    Den Vorschlag mit der Mount-Unit muss ich mir noch ansehen. Ich bin nicht sehr optimistisch, weil die Auswertung der dmesg-Meldungen absolut reproduzierbar sind und eine harte Grenze darzustellen scheinen.

  • Ist das Verhalten gleich, wenn du die SSD erst nach dem Booten anschliesst? Es scheint so, als würde etwas bei der Erkennung dauern. K.A. ob das noch hilfreiche Informationen liefert, aber versuchen kann man es ja mal: Ein zweites Shell Fenster aufmachen und journalctl -f eingeben und dann in der anderen Shell den Mountaufruf mit der Option -v. Oder die SSD anschliessen und das Journal beobachten.

    Wie ist die SSD angeschlossen? Direkt an USB, oder mittels Adapter?

  • Ist das Verhalten gleich, wenn du die SSD erst nach dem Booten anschliesst?

    Ja, genau das habe ich in dem Beitrag vorher beschrieben. Es ist völlig egal, auf welche Weise die SSD gemounted wird, frühestens nach ca. 36Sekunden ist der Zugriff auf das Dateisystem möglich.

    Unten steht das Journal von journalctl -f

    Wie bin ich vorgegangen:

    Raspi neu gestartet

    Von zwei Terminalfenster aus fast zeitgleich eingeloggt

    In einem Fenster gleich journalctl -f gestartet

    Im anderen den Mount-Befehl gestartet, der erst nach ca. einer halben Minute abgeschlossen war. Hier das Logfile:pi@raspi4G:~ $ journalctl -f

    Die Zeile nach den #### (von mir eingefügt) gibt wohl einen Hinweis, aber was bedeutet es?

  • veloci Wow, das hat es gebracht! Herzlichen Dank! Auszug aus dmesg:

    Code
    pi@raspi4G:~ $ dmesg | grep sda
    [    3.611397] sd 0:0:0:0: [sda] 234455040 512-byte logical blocks: (120 GB/112 GiB)
    [    3.619606] sd 0:0:0:0: [sda] Write Protect is off
    [    3.624462] sd 0:0:0:0: [sda] Mode Sense: 47 00 00 08
    [    3.625102] sd 0:0:0:0: [sda] Disabling FUA
    [    3.629307] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [    3.640808]  sda: sda1
    [    3.645971] sd 0:0:0:0: [sda] Attached SCSI disk
    [    7.433849] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

    Man beachte den enorm geschrumpften zeitlich Abstand zwischen der Identifizierung der Partition der SSD bei [3.640808] und dem Einhängen des Dateisystems bei [7.433849], vorher war das bei [36.+]!

Jetzt mitmachen!

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