Externe HDD 18 TB (ext4 formatiert) braucht über eine Minute, bis sie nach Starten einsatzbereit ist

[Chris]

Hallo,

in letzter Zeit nervt mich meine externe Festplatte doch zunehmend, weil sie insgesamt ca. 1 Minute 15 Sekunden braucht, bis sie nach dem Einschalten benutzbar ist.

Ca. 15 Sekunden benötigt die Festplatte (WD Elements Desktop, 18 TB) schon mal bis sie überhaupt hochgefahren ist - okay, das ist bei diesen großen heliumgefüllten Teilen offenbar so, da kann man nichts ändern.

Aber dann rödelt sie nochmal ca. eine knappe Minute rum, so als würde ein System-Check durchgeführt oder eine Indexierung stattfinden (habe ich aber in den Systemeinstellungen (Manjaro KDE) unter Suchen komplett ausgeschaltet). Dass es letzteres eher nicht ist, sehe ich auch daran, dass eine ähnliche Festplatte (WD Elements Desktop, 16 TB), welche NTFS formatiert ist, dieses Verhalten nicht zeigt. Sie braucht halt auch ihre 15 Sekunden, ist dann aber auch bereit, d.h. es kann mit Fullspeed gelesen und geschrieben werden.

Bei der ext4 formatierten Platte kann ich während des "Rödel-Vorgangs" zwar auch schon schreiben und lesen, das läuft dann aber im Schneckentempo, weil die Festplatte halt noch irgendwie mit sich selbst beschäftigt ist.

Andererseits findet dieser Rödel-Vorgang nicht statt, wenn ich die Platte nur einschalte, aber nicht einhänge!

Diese Tendenz mit diesem Rödel-Vorgang nach dem Einschalten kenne ich auch schon von anderen kleineren Festplatten. Aber bei einer 1 TB HDD ist das in wenigen Sekunden erledigt und fällt nicht störend ins Gewicht. Aber je größer die Festplatte wird, desto länger dauert der Vorgang!
Und jedes Mal eine Minute lang warten und Däumchen drehen, bevor man dann mal eben "schnell" was auf die Platte schieben kann, nervt schon!

Jetzt habe ich mal ein wenig recherchiert und bin u.a. auf die Erklärungen im Arch-Wiki gestoßen:
https://wiki.archlinux.org/title/Ext4#D ... ime_update

Informativer fand ich aber die (deutsche) Erklärung bei
https://www.thomas-krenn.com/de/wiki/Ext4_Dateisystem

Und vor allem bei:
https://wiki.ubuntuusers.de/Dateisystemcheck/

Es gibt also tatsächlich einen Dateisystemcheck!
Erst wollte ich diesen reflexartig abschalten!
Aber dann dachte ich mir, schaust vielleicht zuerst mal, wie der aktuelle Status überhaupt ist (wenn die Befehle dafür schon aufgelistet werden):

Code: Alles auswählen

    ~  sudo tune2fs -l /dev/sdb1 | grep -i "mount count"                                                                        1|1 ✘
Mount count:              262
Maximum mount count:      -1
    ~  sudo tune2fs -l /dev/sdb1 | grep -i "check"                                                                                  ✔
Last checked:             Wed Jul 13 15:45:44 2022
Check interval:           0 (<none>)
Checksum type:            crc32c
Checksum:                 0xdcf971e8

Demnach ist also gar nichts eingerichtet?!
Aber was rödelt dann immer so lange unmittelbar BEI JEDEM EINSCHALTVORGANG?

[LaGGGer]

Aber was rödelt dann immer so lange unmittelbar BEI JEDEM EINSCHALTVORGANG?

Ok, du hast einen Vergleich, du sagst die 16TB Platte ist schneller am Start.
Ich nehme mal an Du nutzt USB3. Wenn beide am selben Port hängen, und die 16er ist schneller als die 18er, liegts imho an der Platte.

• Hast du es mal an einem anderen System getestet?

• Nutzt du bei beiden die gleiche USB Verbindung? Dasselbe Kabel?

• Sind beide Platten vom gleichen Hersteller? Welche Hersteller?

[Chris]

Ja, also wie gesagt, ich beobachte das schon seit einer Weile und habe festgestellt, dass ALLE ext4-formatierten Festplatten dieses Rödeln nach dem Einschalten haben.
Ich hatte schon mehrere WD Elements Desktop, z.B. eine 14 TB und jetzt die mit 18 TB (in ext4), ich habe hier aber auch eine alte WD Green, eine interne 1 TB HDD, welche ich aber extern über einen SATA/USB-Adapter betreibe.
Je größer die Platten werden (und insofern mit ext4 formatiert), desto länger rödeln sie nach dem Einschalten (und Einhängen) rum.
Bei der 1 TB Platte sind es nur wenige Sekunden, müsste ich mal genau stoppen, aber ich würde wetten, wenn man das mit 18 multipliziert, kommt man ungefähr auf eine Minute.

Dass es am Kabel liegt, kann ich eigentlich auch ausschließen, da wie gesagt verschiedene HDDs mit verschiedenen Kabeln.

Angeschlossen über USB 3.0 (nach der früheren Bezeichnung).

Über ein anderes System habe ich es noch nicht probiert, muss ich gleich (wenn ich etwas mehr Zeit habe) mal mein Laptop rausholen und ausprobieren ... (melde mich dann nochmal und update hier)

Edit: So, gerade mal die 18er WD Elements mit dem Laptop probiert (auch Manjaro KDE), dort zeigt sie genau das gleiche Verhalten.
Ich denke, das muss irgendwas mit dem ext4 zu tun haben.

PS: Ich habe auch noch mehrere in NTFS formatierte Festplatten (alle extern genutzt) aus Windows-Zeiten, z.B. eine WD Green 1 TB (genau, wie die o.g., welche ext4 formatiert ist) oder eine WD RED 3 TB, die dieses Verhalten alle NICHT zeigen.

[LaGGGer]

Du könntest einmal versuchen deine USB - HDD statisch zu mounten. Wenn das funktioniert, könntest du diese In der fstab eintragen.
Hier wird das erklärt: https://wiki.ubuntuusers.de/Externe_Lau ... einbinden/

Die zweite Möglichkeit die ich gefunden habe ist eine UDEV Regelzu erstellen. Ist aber nicht so einfach: https://wiki.ubuntuusers.de/udev/

Falls du das mounten in der fstab hin bekommst, solltest du unbedingt den Parameter "nofail" anhängen. Das hat den Grund wenn die HHD einmal nicht angeschlossen ist, das System beim hochfahren nicht nach der Platte sucht.
Ohne den Parameter sucht das System (glaube) 2min., erst dann wird der Startvorgang fortgesetzt.

PS
Ist jetzt eigentlich Blödsinn sowas bei dir vorzuschlagen da du eine HHD im Externen Gehäuse hast.
Aber denk trotzdem mal über sowas nach: FANFANTEC 1861 MR-35 SATA HDD Wechselrahmen

FANTEC_1861_S2.png (58.41 KiB) 1208 mal betrachtet

Hat den Vorteil das die HHD am Sata Anschluss hängt. Ist natürlich nichts für Laptops weil du einen freien 51/4" Laufwerksschacht brauchst.
Wie gesagt, ist wahrscheinlich nix für dich, aber ich wollte das mal loswerden

[Chris]

Erst mal Danke für deine Mühen!

Im Moment habe ich allerdings sonst ein bisschen zu viel um die Ohren, um mich damit zu beschäftigen.
Und so gerne möchte ich auch nicht an der fstab rumfummeln, zumal der Erfolg ja auch zweifelhaft ist.

Gibt es denn hier andere, die auch große externe HDDs in ext4 formatiert haben und das Problem mit dem langen Rumrödeln nach dem Starten/Einhängen bestätigen können oder nicht bestätigen können?

Weil wie gesagt, bei mir besteht das Problem grundsätzlich bei externen HDDs, bei ext4.
Als Vergleich habe ich bis jetzt halt nur mehrere HDDs in NTFS, wo das Problem nicht auftritt.

Intern habe ich nur zwei SSDs verbaut (die größte hat 1 TB) und da kann man naturgemäß das Problem dann nicht so nachvollziehen.
Auch wenn dort vermutlich auch dieser Selbst-Check-Vorgang oder was auch immer es ist, läuft, fällt er bei der Größe nicht ins Gewicht und würde vermutlich auch viel schneller laufen, aufgrund der höheren Zugriffsgeschwindigkeiten.

Ich muss das dann erst mal so ungelöst offen stehen lassen.

Eine andere Idee ist aber, zukünftig ext4 zumindest bei den großen Daten-Platten zu vermeiden und vielleicht XFS zu nehmen. (Oder hat jemand einen anderen besseren Formatierungsvorschlag?)
Da bei meinen großen externen HDDs sowieso meist ein recht reger Wechsel herrscht (habe vor schon wieder bald aufzurüsten), könnte ich dann demächst die neue XFS formatieren und dann die vorhandene (die dann Backup wäre) dann auch neu formatieren und wieder bespielen.
Es soll ja sogar eine Möglichkeit geben, ext4 "on the fly" in XFS umzuwandeln, aber ich glaube, davon will ich bei meinen Kenntnissen auch erst mal absehen! Zumal dabei eine Voraussetzung oder dringende Empfehlung wäre, dass noch mind. 10% freier Speicher vorhanden ist, was ich schon nicht mehr habe.

[Allfred]

Hast Du Dich schon mal eingelesen in ReiserFS bzw. Reiser4 ?
https://de.wikipedia.org/wiki/Reiser_File_System
Welches Filesystem Du einsetzt, hängt auch von der Art Deine Daten ab: viele Kleine vs. Backup Monster.
Mir wäre wichtig, daß das Dateisystem nativ vom Kernel unterstützt wird:
==> ReiserFS in der Version 4 vom Linux-Kernel vollständig unterstützt

[gosia]

Hallo Chris,

so gerne möchte ich auch nicht an der fstab rumfummeln, zumal der Erfolg ja auch zweifelhaft ist.

naja, zumindest in der Zukunft würde ich das doch vorschlagen. Es ist ja schnell gemacht, und auch wenn der Erfolg zweifelhaft ist, so bringt es doch Gewissheit, ob z.B. die Option noatime was bringen würde oder nicht. So ist das alles etwas wie "Stochern im Nebel". Zumal ein Check von ext4 ja durchaus nicht jedesmal durchgeführt wird, sondern eigentlich nur, wenn ein Grund vorliegt, defektes Filesystem, nach x-mal booten, ein

Code: Alles auswählen

fsck.mode=force

im Grub wäre das, was mir so einfällt. Am wahrscheinlichten erschien mir am Anfang defektes Filesystem, aber wenn Du sagst, es tritt jedesmal auf und auch mit verschirdenen FP, wird es das wohl nicht sein. Schon mal den USB-Anschluss gewechselt?
Aber als Versuch, etwas Licht ins Dunkle zu bringen, poste doch mal die Ausgabe von

Code: Alles auswählen

systemd-analyze blame

viele Grüsse gosia

PS. kannst aber auch einfach zu XFS oder einem anderen Filesystem wechseln. Vielleicht bringt es das auch schon was...

[gosia]

Hallo Allfred,

ReiserFS bzw. Reiser4

würde ich aber abraten, da spätestens ab Kernel 5.18 die Sclussrunde eingeläutet wird:
"Das Dateisystem [ReiserFS] wurde in Linux 5.18 nun als "deprecated" (veraltet) markiert. Es ist zudem vorgesehen, es 2025 aus dem Mainline-Kernel zu streichen"
https://www.heise.de/news/Linux-5-18-ko ... ?seite=all

viele Grüsse gosia

[Allfred]

So wie ich das lese ist ReiserFS nicht Reiser4.
Das scheint recht unglücklich (beabsichtigt?) ausgedrückt worden zu sein.
"Reiser4 ist vollständig neu entwickelt und sollte nicht mit dem alten ReiserFS verwechselt werden. Daher wird es nicht als „ReiserFS 4“ vertrieben."

[Chris]

Ja, den USB-Anschluss habe ich auch schon gewechselt.
Ich habe dafür im Wesentlichen zwei Anschlüsse zur Verfügung, an dem einen hängt die ext4-formatierte, an dem anderen die NTFS-formatierte. Die habe ich einfach mal getauscht - ohne Änderung! (ext4 rödelt weiterhin, NTFS nicht.)

Hier mal die o.g. Ausgabe:

Code: Alles auswählen

    ~  systemd-analyze blame                                                                                                        ✔ 
   5min 83ms archlinux-keyring-wkd-sync.service
2min 20.731s pkgfile-update.service
      1.015s apparmor.service
       900ms systemd-random-seed.service
       588ms man-db.service
       502ms dev-nvme0n1p3.device
       304ms pamac-mirrorlist.service
       279ms tlp.service
       252ms pamac-cleancache.service
       214ms firewalld.service
       192ms systemd-udev-trigger.service
       186ms dev-loop3.device
       185ms dev-loop7.device
       181ms dev-loop4.device
       179ms dev-loop10.device
       176ms dev-loop5.device
       171ms snapd.service
       159ms dev-loop11.device
       155ms systemd-modules-load.service
lines 1-19

Mit den Änderungen an der fstab tue ich mich etwas schwer, weil ich das
a) jetzt nicht so schnell hinkriege
b) ich früher schon mal an der fstab rumgepfuscht habe (das hatte damals irgendwas mit einer Festplatte zu tun, die veracrypt-verschlüsselt war, bzw. einen Container enthielt (wenn die ganze Platte verschlüsselt ist, wird sie ja sowieso erst mal nicht erkannt), jedenfalls war die abschließende Erkenntnis damals für mich, dass man (wenn man wenig Ahnung davon hat!) möglichst am besten die Finger von der fstab lässt, und, dass in der fstab so wenig wie möglich drin stehen sollte (weil, dann weniger Fehlerpotenzial) und nur das, was das System halt (bei der Installation) selbst anlegt.
c) denke ich aber auch irgendwo, so eine externe Festplatte sollte einfach so eingehängt werden könnnen, ohne, dass ich mir die Mühe machen muss, die fstab zu modifizieren. Wie gesagt, ich tausche die Externen auch schon mal öfter aus, weil ich mir was Neues kaufe und das Alte verkaufe, da müsste ich das dann ja jedes Mal in der fstab ändern, sonst hätte ich mit ext4 wieder die gleichen Probleme (vorausgesetzt, das würde überhaupt was bringen).
Ich denke, da würde ich das Problem wirklich lieber versuchen zu umgehen, indem ich eine andere Formatierung wähle.

[gosia]

Hallo Chris,
2 Minuten für pkgfile-update und 5 Minuten für archlinux-keyring, das sind ja Zeiten zum Schlechtwerden Dummerweise wüsste ich aber nicht, was die mit deiner externen FP zu tun haben, denn da sind doch wohl nur Daten drauf, oder?
Beides hängt mit der Netzwerkverbindung zusammen, das eine macht ein Update der Paketdateien und das andere ditto für den Keyring. Kann dauern, wenn noch kein Netzwerk da ist oder Du deine Pakete unbedingt aus Australien holen möchtest. Allerdings passiert das in der Regel auch nur einmal täglich und wie gesagt, einen direkten Zusammenhang mit der externen FP kann ich nicht sehen, ausser, dass das Systen erstmal zu beschäftigt ist um sich sofort ums mounten zu kümmern. Halte ich aber für unwahrscheinlich. Was passiert denn, wenn Du beide Dienste mal deaktivierst?
Aber gut, wenn es dir lieber ist, probiere ein anderes Filesystem aus. Wenn es was bringt ist es gut, auch wenn ich solchen Sachen gern auf den Grund gehe.

viele Grüsse gosia

[gosia]

Hallo Allfred,

Das scheint recht unglücklich (beabsichtigt?) ausgedrückt worden zu sein.

Da kann ich dir zumindest nicht widersprechen. Auch bei nochmaligem Lesen ist die Terminologie sehr unklar.
ReiserFS = allgemeine Bezeichnung für das Reiser Filesystem?
Reiser4 = Version 4 von ReiserFS?
oder gar
Reiser4 != ReiserFS?
na hör auf, noch unglücklicher ginge ja gar nicht mehr, zumal es auch noch ReierFS 5 gibt, bzw. es wird daran gebastelt. Fragezeichen über Fragezeichen, klar sieht anders aus. Da müsste ich mich intensiver damit beschäftigen um das entscheiden zu können. Trotzdem bleibt ein ungutes Bauchgefühl...
Aber egal, ich habe den Verdacht, dass das Problem woanders liegt, besonders wenn ich mir die Ausgabe von ansehe. Das erläutere ich aber mal direkt als Antwort auf das Posting von Chris.
Da wäre es sowieso gut, wenn noch andere ihre Ideen einbringen, denn das Ergebnis von systemd-analyze blame ist für mich auch ziemlich unklar.

viele Grüsse gosia

[Chris]

Zu den komischen Zeiten von pkgfile-update und archlinux-keyring:

Eigentlich dachte ich, ich hätte den pkgfile-update.timer mal deaktivert, aber eine Statusabfrage zeigt irgendwie etwas anderes?!

Code: Alles auswählen

   ~  systemctl status pkgfile-update.timer                                                                                        ✔
● pkgfile-update.timer - pkgfile database update timer
     Loaded: loaded (/usr/lib/systemd/system/pkgfile-update.timer; enabled; preset: disabled)
     Active: active (waiting) since Mon 2023-02-27 12:59:44 CET; 5 days ago
      Until: Mon 2023-02-27 12:59:44 CET; 5 days ago
    Trigger: Sun 2023-03-05 00:00:00 CET; 1h 5min left
   Triggers: ● pkgfile-update.service

Ich weiß jetzt nicht, wie das zu deuten ist "...enabled; preset: disabled" (Eingeschaltet, obwohl die Vorauswahl eigentlich aus ist?)

Ein erneutes:

Code: Alles auswählen

systemctl disable pkgfile-update.timer

ergibt dann:

Code: Alles auswählen

   ~  systemctl status pkgfile-update.timer                                                                                        ✔ 
● pkgfile-update.timer - pkgfile database update timer
     Loaded: loaded (/usr/lib/systemd/system/pkgfile-update.timer; disabled; preset: disabled)
     Active: active (waiting) since Mon 2023-02-27 12:59:44 CET; 5 days ago
      Until: Mon 2023-02-27 12:59:44 CET; 5 days ago
    Trigger: Sun 2023-03-05 00:00:00 CET; 1h 1min left
   Triggers: ● pkgfile-update.service

Warum ich das ausgeschaltet haben wollte? Ich weiß es nicht mehr genau, ich meine, das hätte eben auch diese Benachrichtigung in der Taskleiste erzeugt, dass es Updates gibt, und das hat mich gestört (weil das halt mitunter ein paar Mal die Woche vorkam).
Ich mache die Updates lieber selbst, prüfe ca. wöchentlich manuell.

Aber warum die beiden Sachen (jetzt mal unabhängig davon) so lange brauchen ... könnte sein, dass das mit meinem VPN-Dienst und dem im Hintergrund laufenden Network Lock zusammenhängt! Letzterer sollte eigentlich alle Dienste durch den VPN-Tunnel zwingen.
Aber eigentlich nutze ich so gut wie immer deutsche VPN-Gateways und die laufen fast ohne Geschwindigkeitseinbußen.
Und meine Mirror-List sieht wie folgt aus:

Code: Alles auswählen

sudo pacman-mirrors                                                                                                          ✔ 
[sudo] Passwort für john: 
Pacman-mirrors version 4.23.2
Local mirror status for stable branch
Mirror #1   OK  00:15   Germany      https://mirror.moson.org/manjaro/
 Mirror # 2 https://mirror.informatik.tu-freiberg.de/manjaro/ does not exist
Mirror #3   OK  09:03   Belgium      http://ftp.belnet.be/mirrors/manjaro/repos/
Mirror #4   OK  02:36   Germany      https://mirror.23m.com/manjaro/
Mirror #5   OK  01:05   Netherlands  https://manjaro.mirrors.lavatech.top/
Mirror #6   OK  18:35   Germany      https://mirrors.xtom.de/manjaro/
Mirror #7   OK  06:35   Netherlands  http://ftp.snt.utwente.nl/pub/linux/manjaro/
Mirror #8   OK  01:03   Belgium      https://mirror.futureweb.be/manjaro/
Mirror #9   OK  02:55   Germany      https://mirror.netcologne.de/manjaro/
Mirror #10  OK  00:15   Austria      https://mirror.easyname.at/manjaro/
Mirror #11  OK  00:05   Germany      https://mirror.alpix.eu/manjaro/
Mirror #12  --  513:39  Austria      https://mirror.alwyzon.net/manjaro/
Mirror #13  OK  02:35   Germany      http://ftp.tu-chemnitz.de/pub/linux/manjaro/
Mirror #14  OK  00:26   Switzerland  https://mirror.init7.net/manjaro/
Mirror #15  OK  05:05   Netherlands  https://ftp.nluug.nl/pub/os/Linux/distr/manjaro/
Mirror #16  OK  00:36   Switzerland  https://manjaro.osmir.ch/
Mirror #17  OK  00:26   Germany      https://ftp.gwdg.de/pub/linux/manjaro/
Mirror #18  OK  00:35   Germany      https://ftp.halifax.rwth-aachen.de/manjaro/
Mirror #19  OK  04:57   Netherlands  https://mirror.koddos.net/manjaro/

Hmm ... noch eine Baustelle! Mirror #2 und #12 haben wohl Probleme.
Die Liste habe ich jetzt gerade mal aktualisiert mit:

Code: Alles auswählen

sudo pacman-mirrors --country Germany,Belgium,Netherlands,Austria,Switzerland

Aber nochmal zum eigentlichen Thema:
Ja, auf der externen HDD sind nur Daten drauf, nichts systemrelevantes.

[Benutzer 1396 gelöscht]

Mal ein ganz anderer Denkansatz:
Ich betreibe mehrere Inateck Festplattengehäuse 3.5 USB 3.0. Der Controller von Inateck unterstützt angeblich nur Festplatten bis maximal 12TB. Ein Kollege von mir betreibt darin aber völlig problemlos eine NTFS-formatierte IronWolf 14TB. Schaue doch bitte einmal nach, für welche maximale Festplattenkapazität dein Gehäuse freigegeben ist. Eventuell funktioniert ext4 nur innerhalb dieser Spezifikation fehlerfrei?

[Chris]

Nee, die beiden großen Festplatten (16 TB (NTFS), 18 TB (ext4) sind beide wie gesagt WD Elements Desktop, also die sind im Original Gehäuse. Und ich gehe natürlich davon aus, dass, wenn WD die so ausliefert, die Controller auch mit den verbauten Platten umgehen können.

Bei den kleineren Festplatten (bis max. 3 TB) nutze ich so Fideco SATA/USB-Adapter (gibt es so im Moment nicht mehr zu kaufen), aber bis 3 TB gehen die allemal, ich hatte da auch schon eine 14 TB Platte dran.

PS: Aber wenn du schreibst, dass du mehrere Inatek-Festplattengehäuse betreibst, sind die dann auch ext4 formatiert und kannst du sagen, dass du dieses Rumrödeln nach dem Einhängen nicht kennst?

Ich habe jetzt gerade noch mal bei meiner WD Green (1 TB) geschaut, die rödelt so ca. 4 Sekunden rum. Wie gesagt, da ist das noch unauffällig.
Bei einer 14 TB Platte, die ich mal hatte, waren es so ca. 45 Sekunden und bei der 18 TB Platte ist es dann die Krönung mit einer Minute!