Linux Konstanter Schreibzugriff auf Festplatte | ext4 Inodes Initialisierung

[Ambrosius]

Ich hab hier eine rotierende HDD, die ich jüngst als ext4 formatiert habe und so weit so gut. Jedes Mal wenn ich sie mounte kommt es zu einer kontinuierlichen Schreiborgie, die nimmer enden will. Per Monitoring sehr ich zwischen 4 - 8MiB/s die fortlaufend geschrieben werden, die LED auf der externen Festplatte blinkt wie bei allen Schreibaktivitäten üblich.. Ich hab das nun mehrfach gelöscht und wiederholt, aber irgendwas schreibt auf die Platte, ohne dass ich sehen kann was und wer.

[ 6223.958435] usb 3-2: new SuperSpeed USB device number 2 using xhci_hcd
[ 6223.979610] usb 3-2: New USB device found, idVendor=1058, idProduct=0837, bcdDevice=10.72
[ 6223.979628] usb 3-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 6223.979635] usb 3-2: Product: My Passport 0837
[ 6223.979639] usb 3-2: Manufacturer: Western Digital
[ 6224.600420] usb-storage 3-2:1.0: USB Mass Storage device detected
[ 6224.600625] scsi host6: usb-storage 3-2:1.0
[ 6224.600727] usbcore: registered new interface driver usb-storage
[ 6224.604107] usbcore: registered new interface driver uas
[ 6225.627106] scsi 6:0:0:0: Direct-Access     WD       My Passport 0837 1072 PQ: 0 ANSI: 6
[ 6225.627655] scsi 6:0:0:1: Enclosure         WD       SES Device       1072 PQ: 0 ANSI: 6
[ 6225.629833] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 6225.630177] scsi 6:0:0:1: Attached scsi generic sg3 type 13
[ 6225.631036] sd 6:0:0:0: [sdc] Spinning up disk...
[ 6226.650289] .....ready
[ 6231.145872] sd 6:0:0:0: [sdc] 3906963456 512-byte logical blocks: (2.00 TB/1.82 TiB)
[ 6231.146252] sd 6:0:0:0: [sdc] Write Protect is off
[ 6231.146259] sd 6:0:0:0: [sdc] Mode Sense: 53 00 10 08
[ 6231.146638] sd 6:0:0:0: [sdc] No Caching mode page found
[ 6231.146645] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 6231.191158]  sdc: sdc1
[ 6231.191332] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 6231.198385] scsi 6:0:0:1: Failed to get diagnostic page 0x1
[ 6231.198392] scsi 6:0:0:1: Failed to bind enclosure -19
[ 6231.198425] ses 6:0:0:1: Attached Enclosure device
[ 7131.041785]  sdc:
[ 7131.065476]  sdc:
[ 7356.453283]  sdc: sdc1
[ 7380.440877]  sdc: sdc1
[ 7380.446190]  sdc: sdc1
[ 7440.717143] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Quota mode: none.

Könnte es was mit

Failed to get diagnostic page 0x1

zu tun haben? Ich hab das mal geinternettet, hab vieles zu Mount Problemen gefunden, die habe ich aber nicht. Die Platte lässt sich einbinden und auch von mir mit Daten befüllen, aber was hat es mit dieser komischen Schreiberei auf sich?

Auch mal gleich versuchsweise auf ner anderen Machine versucht: gleiches Verhalten. Liegt also nicht am OS. Die Platte war vorher unauffällig. War allerdings vorher als NFTS Platte formatiert, insgesamt nicht viel gelaufen. Alle SMART Werte geprüft, keine wiederhergestellen Sektoren, nikkes.


Hier noch der fsck output:

$ sudo e2fsck -f -y -v /dev/sdc1
e2fsck 1.47.0 (5-Feb-2023)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

          11 Inodes sind in Benutzung (0.00% von 122093568)
           0 nicht zusammenhängende Dateien (0.0%)
           0 nicht zusammenhängende Verzeichnisse (0.0%)
             # von Inodes mit ind/dind/tind Blöcken: 0/0/0
             Histogramm der Tiefe von Erweiterungen: 2/1
     7946709 Blöcke werden benutzt (1.63% von 488369920)
           0 defekte Blöcke
           1 große Datei

           0 reguläre Dateien
           2 Verzeichnisse
           0 zeichenorientierte Gerätedateien
           0 Blockgerätedateien
           0 Fifos
           0 Verknüpfungen
           0 symbolische Verknüpfungen (0 schnelle symbolische Verknüpfungen)
           0 Sockets
------------
           2 Dateien

Diese "1 große Datei" ist wohl was er die ganze Zeit schreibt, aber ich kann diese Datei nicht ausfindig machen.
HDD lässt sich problemlos übers Terminal und Dateimanager unmounten.... ich bin ratlos..

 

[zwieblum]

Swap-partition?

 

[hoday]

Könnte es was mit

Failed to get diagnostic page 0x1

zu tun haben? Ich hab das mal geinternettet, hab vieles zu Mount Problemen gefunden, die habe ich aber nicht. Die Platte lässt sich einbinden und auch von mir mit Daten befüllen, aber was hat es mit dieser komischen Schreiberei auf sich?

Nicht zwingend. Bei Festplatten mancher Hersteller kommen solche Meldungen im Journal während dem Mounten immer. Der Auszug aus dem Journal den du hier gepostet hast, schaut für mich jetzt erstmal nicht auffällig aus.

 

[fraaanz]

Ich hab hier eine rotierende HDD, die ich jüngst als ext4 formatiert habe und so weit so gut. Jedes Mal wenn ich sie mounte kommt es zu einer kontinuierlichen Schreiborgie, die nimmer enden will. Per Monitoring sehr ich zwischen 4 - 8MiB/s die fortlaufend geschrieben werden,

Ext4 format arbeitet "lazy".
mkfs.ext4 bzw der Formatierungsbefehl retourniert sofort, die eigentlichen ext4 Verwaltungsstrukturen werden dann im Hintergrund wenn gerade sonst nichts zu tun ist angelegt.
Einfach warten, irgendwann ist das fertig.

 

[Ambrosius]

Ext4 format arbeitet "lazy".
mkfs.ext4 bzw der Formatierungsbefehl retourniert sofort, die eigentlichen ext4 Verwaltungsstrukturen werden dann im Hintergrund wenn gerade sonst nichts zu tun ist angelegt.
Einfach warten, irgendwann ist das fertig.

Tatsache? Ist das nur weil es eine langsame HDD ist, dass man diese Hintergrundaktivität sonst nicht bemerkt? Ich hatte die Platte ca. 1 Stunde laufen lassen, war aber immer noch nciht durch..

Vielleicht am Rande noch: Hatte auch kurz überlegt ext2 für die Backupfestplatte nutzen. Aber für den Fall dass die Partitionstabelle sich wieder verabschiedet, wie in der Vergangenheit auch gerne hier und da passiert, sollte man da lieber doch das Journaling Feature beibehalten?

 

[zwieblum]

Bedingt. Bei mkfs werden die IOs gepuffert und landen zuerst mal im Cache - und der kann fast so groß sein wie dein RAM. ein beherztes "sync" befördert die dann auf die Platte. "watch iostat" zeigt dir an, was gerade passiert und wann der Puffer leer ist. Wenn du ein gemountetes Filesystem hast ist die Sache im Prinzip gleich - nicht alle Änderungen landen auf der Platte (da gibt's ein paar Kernelparameter (vm.dirty_writeback_centisecs ...) zum Steuern. Im Endeffekt hat die Platte immer was zu tun - ausser du kennst dein Systm gut genug um das abzustellen.

Für's "Backup" wäre ein Filesystem gut, das selbstheilende Features hat (ZFS ...) - aber beachte: eine veränderbare Kopie ist kein Backup.

 

[Ambrosius]

Für's "Backup" wäre ein Filesystem gut, das selbstheilende Features hat (ZFS ...) - aber beachte: eine veränderbare Kopie ist kein Backup.

Über ZFS und XFS hatte ich auch nachgedacht. Problem ist, ich kenn mich nicht allzu gut aus und würde die Komplexität iM so gering wie möglich halten, weil es gerade auch einfach schnell gehen muss und ich keine Zeit habe mich in CoW Dateisystem reinzufuchsen. Ich werde das aber in naher Zukunft vertiefter behandeln.

Wie gesagt, jetzt gerade sollte es auch ein einfach mehr plug und play sein, da ich das Backup auch gerne fertigstellen würde.
Deswegen bin ich auch gerade etwas unentschieden.

Kurz zusammengefasst: Meine Vorgehensweise wär im Lichte neuer Erkenntnisse: eine neue Partitionstabelle erstellen, ext4 partition neu erzeugen, mounten und dann bevor ich Daten drauf packe einfach die Hintergrundaktivität abwarten? Nur was zum Henker wird da genau gemacht? die Inodes hat er ja schon erfasst und Daten sind keine drauf, was gibts da sonst noch zu strukurieren und ordnen? Wohl gemerkt es handelt sich um eine magnetische Festplatte a la HDD.

 

[rumbero]

Ich hab hier eine rotierende HDD, die ich jüngst als ext4 formatiert habe und so weit so gut. Jedes Mal wenn ich sie mounte kommt es zu einer kontinuierlichen Schreiborgie, die nimmer enden will. Per Monitoring sehr ich zwischen 4 - 8MiB/s die fortlaufend geschrieben werden, die LED auf der externen Festplatte blinkt wie bei allen Schreibaktivitäten üblich.. Ich hab das nun mehrfach gelöscht und wiederholt, aber irgendwas schreibt auf die Platte, ohne dass ich sehen kann was und wer.

Ein paar konkrete technische Details der Ausganssituation anstelle von Symptomschilderungen und sonstigen sublektiven Interpretationen, die nur zu uferlosen Diskussionen führen, wären schon sehr angebracht.

Mit welchen Parametern genau wurde das mkfs.ext4-Kommando ausgeführt?
Welche mount-Optionen sind in der /etc/fstab für das betroffene Dateisystem eingetragen?

Auf Verdacht: Es empfiehlt sich, unter anderem mittels der mount-Option 'noatime' unnötige Schreibzugriffe auf das Dateisystem zu reduzieren.

 

[fraaanz]

Tatsache?

2. High Level Design — The Linux Kernel documentation

"[...]The INODE_ZEROED flag means that the inode table has been initialized;
mkfs will unset this flag and rely on the kernel to initialize the inode tables in the background."

Vielleicht am Rande noch: Hatte auch kurz überlegt ext2 für die Backupfestplatte nutzen.

Wie kommt man auf die Idee? Ext2 ist überholt, es wurde vor kurzem explizit als "deprecated" markiert und es wird wohl irgendwann entfernt werden: https://www.phoronix.com/news/Linux-6.9-Deprecates-EXT2

für den Fall dass die Partitionstabelle sich wieder verabschiedet, wie in der Vergangenheit auch gerne hier und da passiert

Wie passiert das? Das ist mir seit xx Jahren Linux Nutzung noch nie passiert?

ext4 partition neu erzeugen, mounten und dann bevor ich Daten drauf packe einfach die Hintergrundaktivität abwarten?

Man kann beim mkfs auch per Parameter angeben das alles gleich angelegt wird.
Eine kurze Google Suche meint das geht mit: mkfs.ext4 -E lazy_itable_init=0 /dev/...
"man mkfs.ext4" sagt das auch zu dem Parameter.
Ausprobieren?

 

[Corvus]

Und bei NTFS und FAT32, das bin ich ja gewohnt, funzt es wohl On-Demand nach Schnellformatierung.
Ich wollte mal mal wegen Problemen mit EXT4 am Linux DVB Receiver ne mSD und externe HD mit EXT3 statt 4 formatieren und hab mehrmals abgebrochen nach spätestens ner Viertelstunde, weil Schnellformatierung nicht so lange dauern kann.
Tatsächlich dauerte es aber 20min bei der 64GB SD und vllt doppelt so lang bei der 3TB HD,weil wohl das Journal bzw das Gegenstück zur MFT mit der zur Verfügung stehenden USB3 und bei der SD noch niedrigeren Schreibleistung blockweise geschrieben wurde, auch bei der SD schon ein paar GB. Und nicht etwa im Hintergrund. EXT4 dauert bloß Sekunden.

Zum Titel :
3,5 Zoll NAS Laufwerke können ganz ohne Zugriffe permanent lärmen, aber das hier ist ja wohl ne normale externe 2,5 Zoll. Und dann werden auch keine Schreibvorgänge angezeigt, weil es keine gibt.

Wenn schon Daten drauf sind könnte es Indizierung oder Malware Scan sein.

 

[Ambrosius]

Ich wusste gar nicht wie tief dieser Kaninchenbau geht. Gerade weil es sich um keine SSD handelt, ist mir dieser Hintergrundinitialisierung gar nie aufgefallen.

Mit welchen Parametern genau wurde das mkfs.ext4-Kommando ausgeführt?
Welche mount-Optionen sind in der /etc/fstab für das betroffene Dateisystem eingetragen?

Ja du hast im Prinzip auch recht, ich hatte gar nicht daran gedacht die man page zu konsultieren, weil ich mich sonst immer auf den PArtitionsmanager von KDE verlasse, der auch sonst immer zuverlässig arbeitet. War mit der HDD nur diesemal ein Präzedenzfall für mich, weshalb ich so misstrauisch wurde. Aber mir ist schon klar, dass man die gleichen Befehle die die GUI macht auch händisch in der Konsole anstoßen kann..siehe weiter unten als Alternative nun zur Gui. Zu deinem zweiten Punkt: im fstab habe ich nix eingetragen, da es sich um eine externe Backup Festplatte handelt.

Wie passiert das? Das ist mir seit xx Jahren Linux Nutzung noch nie passiert?

Ist mir mit NFTS in zwei Jahren gleich zwei Mal passiert, unter Linux FS selbst aber noch nie, das stimmt.

Wie kommt man auf die Idee? Ext2 ist überholt, es wurde vor kurzem explizit als "deprecated" markiert und es wird wohl irgendwann entfernt werden: https://www.phoronix.com/news/Linux-6.9-Deprecates-EXT2

war auch mehr ne Schnapsidee als ein Geistesblitz.


Insgesamt hatte ich mich mit dem Thema Inodes nie so richtig beschäftigt, hab auch schon 2TB-große SSDs mit ext4 formatiert, aber noch nie irgendwas mitbekommen, dass da was "nacharbeitet" ... Wieder was gelernt

Ich hab auch dank eurer Hinweise und Stichworte ein bisschen mehr Lesesstoff gehabt und bin u.a. auch auf diesen Baledung Artikel gestoßen, wo mir dieser Formatierungsbefehl mit den ensprechenden Optionen zugesagt hat:

$ sudo mkfs.ext4 /dev/sdx1 -O sparse_super,large_file -m 0 -T largefile4

Da es sich auch tatsächlich um mehr oder weniger große Dateien, die dort geparkt werden sollen, handelt, könnte ich sehr wohl auf largefile4. Spräche sonst was dagegen?

 

[Ambrosius]

Hallo Freunde, hier nochmal ein kurzer Follow-Up:

Nachdem ich mich gestern und heute nochmal vertiefend mit der Materie Dateisystem beschäftigt habe, hab ich letztlich diesen Formatierungsbefehl formuliert:

sudo mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 -v -m 0 -T largefile -L externe_platte /dev/sdb1

Hier auch der Output von mkfs, für die, die es interessiert:

❯ sudo mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 -v -m 0 -T largefile -L externe_platte /dev/sdb1
mke2fs 1.47.1 (20-May-2024)
Dateisystemtypen für das Aufschlüsseln von mke2fs.conf: 'ext4', 'largefile'
/dev/sdb1 enthält Daten von „DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 3906959359 sectors, extended partition table (last)”
Trotzdem fortfahren? (j,n) j
Filesystem label=externe_platte
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=0 Blöcke, Stripebreite=0 Blöcke
1907712 Inodes, 488369920 Blöcke
0 Blöcke (0.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=2636120064
14904 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
128 Inodes pro Gruppe

[..]

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (262144 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt

Ich hab die reservierten Blöcke bewusst auf 0% gesetzt, ich denke als externe Backup Festplatte schieß ich mir damit nciht ins Bein.
Und -T largefile sollte auch mit 1 MiB große Bytes-per-Inode ein guter Kompromiss sein. Im Ergebnis habe ich direkt nach der Formatierung:

Verfügbar: 99% - 1,82 TiB
Belegt: 1% - 1,66 GiB

und nachdem ersten Aus und Wieder-Einhängen:

Belegt: 1% - 2,03 MiB

Damit würde ich sagen: Mission weitestgehend Accomplished


Ganz wie @fraaanz herauspointiert hatte, werden mit den lazy_* Parametern gleich alle Inodes angelegt und es rattert dann nicht mehr ewig nach. Ganz zu meiner Überraschung, hat es aber ingesamt trotzdem nur 60sec gedauert, bis die Formatierung abgeschlossen war. Also inkl. des Anlegens aller Inodes. Ein kurzer Vergleich zeigt:

    ❯ df -i

    Dateisystem       Inodes     IBenutzt     IFrei             IUse%   Eingehängt auf

    /dev/sda1      122101760     7273       122094487    1%

    /dev/sdb1      1907712         7199       1900513          1%

wobei sda1 und sdb1 beide 1,8 TiB groß sind, und beide zu ca. 40% gefüllt sind. Es zeigt sich recht deutlich, dass man für große Dateien insgesamt nicht viele Inodes braucht. 1,9 Millionen Inodes sind völlig ausreichend, wohingegen 122 Mill Inodes zumindest bei ner SSD auch nicht unbedingt weh tun, bei ner HDD sieht das Ganze doch anders aus. Letzlich werden dennoch >nur< 1% für rund die Hälfte der gesamten Platte verreinahmt. Es lohnt sich auch auf jeden Fall das Manual mal zu studieren und sich mit dem Thema auseinanderzusetzen..

 

[fraaanz]

Ganz wie @fraaanz herauspointiert hatte, werden mit den lazy_* Parametern gleich alle Inodes angelegt und es rattert dann nicht mehr ewig nach. Ganz zu meiner Überraschung, hat es aber ingesamt trotzdem nur 60sec gedauert, bis die Formatierung abgeschlossen war.

Naja, einerseits durch "largefile" werden das insgesamt weniger Inodes zum Anlegen, d.h. viel weniger Kopfbewegungen der Festplatte und zweitens läuft es im Vordergrund und nicht bewusst gebremst langsamer im Hintergrund. Aber in Linux lässt sich ja vieles auf den konkreten Anwendungsfall hin optimieren.
Willkommen in der Gruppe der regelmäßig externe Backup-Macher!
Sonntag ist Backup Tag!

 

[linrunner]

Jetzt ist aber immer noch nicht klar, woher das ursprüngliche Phänomen, der "konstante Schreibzugriff", kam.

 

[mtu]

Jetzt ist aber immer noch nicht klar, woher das ursprüngliche Phänomen, der "konstante Schreibzugriff", kam.

Doch, hier:

Ext4 format arbeitet "lazy".
mkfs.ext4 bzw der Formatierungsbefehl retourniert sofort, die eigentlichen ext4 Verwaltungsstrukturen werden dann im Hintergrund wenn gerade sonst nichts zu tun ist angelegt.
Einfach warten, irgendwann ist das fertig.

 

[Ambrosius]

Genau es war die Hintergrundinitialisierung der Inodes, das nachsitzen muss. Bei einer SSD fällt es ob der schnellen Zugriffszeiten und Schreibgeschwindigkeit nicht auf wenn man mkefs mit den Standardwerten ausführt.

 

[linrunner]

Ah ok, hier stand es ja auch.

es rattert dann nicht mehr ewig nach. Ganz zu meiner Überraschung, hat es aber ingesamt trotzdem nur 60sec gedauert, bis die Formatierung abgeschlossen war.