mdadm config - wo ist der Speicher?

[SFFox]

LÖSUNG: Es waren die Reserved Blocks (5% default) vom Filesystem.

---

Hey, das ist vielleicht einfaches Anfänger-Wissen, das mir in meinem Inselwissen fehlt. Es geht um klassisches mdadm Raid auf einem Ubuntu Server mit ext4 Partition.

md0 ist ein ext4 Raid1 Array (4kb Blocksize) mit einem Spare (3x 8TB HDD).
Chunksize sieht seltsam aus, ist aber sowieso irrelevant für Raid1.
md1 ist ein ext4 Raid0 Array (4kb Blocksize) aus 2x 4TB SSDs.

Es fand ein "rsync -ah --delete" statt zwischen den Laufwerken. "tree" spuckt die selbe Datei-Anzahl aus.
"df -h" zeigt die selbe Größe an, gleich viel belegten Speicher, aber dennoch unterschiedlich viel freien Speicher.
Warum matched der "freie Speicher" nicht? Wo kommt die Differenz her? Rechne ich da was falsch? Fressen Raid1 Meta Informationen 400GB? Wenn ich simpel danach google kommt natürlich immer die Standard-Antwort "Raid1 verbraucht die Hälfte der raw capacity"... aber das ist mir klar... man spiegelt ja eine Platte

Danke schon mal für die Nachhilfe

#df -h
/dev/md0  7,3T    4,4T  2,5T
/dev/md1  7,3T    4,4T  2,9T

#cat /proc/mdstat
md0 : active raid1 sdd1[2] sdc1[1] sdb1[3](S)
      7813893120 blocks super 1.2 [2/2] [UU]
      bitmap: 0/59 pages [0KB], 65536KB chunk

md1 : active raid0 sde1[0] sdf1[1]
      7813770240 blocks super 1.2 512k chunks

#sudo mdadm --detail /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : Sun Jun 29 01:50:43 2025
        Raid Level : raid0
        Array Size : 7813770240 (7.28 TiB 8.00 TB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Sun Jun 29 01:50:43 2025
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

            Layout : original
        Chunk Size : 512K

Consistency Policy : none

              Name : myserver:1  (local to host myserver)
              UUID : 61cfff13:5ca5c984:a4d75cf0:2a04a93v
            Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       65        0      active sync   /dev/sde1
       1       8       81        1      active sync   /dev/sdf1

#sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Sun Oct 21 14:11:21 2018
        Raid Level : raid1
        Array Size : 7813893120 (7.28 TiB 8.00 TB)
     Used Dev Size : 7813893120 (7.28 TiB 8.00 TB)
      Raid Devices : 2
     Total Devices : 3
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Tue Jul 15 02:36:45 2025
             State : clean
    Active Devices : 2
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 1

Consistency Policy : bitmap

              Name : myserver:0  (local to host myserver)
              UUID : 7be54e8e:1cd57bc1:669931dc:b3c2499x
            Events : 162549

    Number   Major   Minor   RaidDevice State
       2       8       49        0      active sync   /dev/sdd1
       1       8       33        1      active sync   /dev/sdc1

       3       8       17        -      spare   /dev/sdb1

 

[schalli110]

Kann es sein, dass der fehlende Speicher in dieser Bitmap hier steckt?

bitmap: 0/59 pages [0KB], 65536KB chunk

 

[KillerCow]

Nicht direkt was zum Thema, aber wenn die dritte Platte in deinem Raid1 einzig als Spare für nur dieses Raid1 dient, dann lass die direkt im Raid mitlaufen als dritte Platte. So sparst du dir das resilver im Falle eines Defekt und hast vielleicht sogar noch ne höhere Leseperformance, weil drei Platten.

 

[mae]

"df -h" zeigt die selbe Größe an, gleich viel belegten Speicher, aber dennoch unterschiedlich viel freien Speicher.
Warum matched der "freie Speicher" nicht? Wo kommt die Differenz her? Rechne ich da was falsch? Fressen Raid1 Meta Informationen 400GB?

Waere mir neu, und wir haben viele Jahre lang RAID1 mit md verwendet (sind aber jetzt auf btrfs und ZFS und deren eingebautes RAID1 umgestiegen).

#df -h
/dev/md0  7,3T    4,4T  2,5T
/dev/md1  7,3T    4,4T  2,9T

Wenn man's genau wissen will, vielleicht doch ohne -h. Und bitte auch die header-Zeile zeigen, und im Text beschreiben, was Du mit "freie Speicher" meinst. So habe ich erst einmal in der grossen Menge von gezeigten Daten raten muessen, was Du meinst.

Ergänzung (16. Juli 2025)

Du kannst uebrigens mit

mdadm --grow --bitmap=none /dev/md0

die Bitmap ausschalten und solltest dann etwas mehr freien Speicher sehen, aber ich erwarte, dass es sich dabei um weniger als ein MB handelt. Siehe https://louwrentius.com/the-impact-of-the-mdadm-bitmap-on-raid-performance.html

Ergänzung (16. Juli 2025)

Noch eine Ergaenzung: Die Bitmap ist ein Ding von md, und Du siehst die Groesse, die uebrigbleibt, bei df als 7,3T angegeben, bzw. in den "7813893120 blocks", die in /proc/mdstat angezeigt werden. Es liegt also einzig und allein am Filesystem, wenn da 400GB weniger Platz verfuegbar sind. Eine Moeglichkeit ist, dass beim Dateisystem auf md0 5% mehr Reserve eingestellt sind als beim Dateisystem auf md1. Ein anderes ist, dass da sehr viele kleine Dateien sind, und die Blockgroesse auf md0 groesser (dann wuerde ich aber auch einen hoeheren Wert fuer den belegten Speicher erwarten).

 

[foofoobar]

Es liegt also einzig und allein am Filesystem, wenn da 400GB weniger Platz verfuegbar sind. Eine Moeglichkeit ist, dass beim Dateisystem auf md0 5% mehr Reserve eingestellt sind als beim Dateisystem auf md1. Ein anderes ist, dass da sehr viele kleine Dateien sind, und die Blockgroesse auf md0 groesser (dann wuerde ich aber auch einen hoeheren Wert fuer den belegten Speicher erwarten).

tune2fs liefert belastbare Antworten.

 

[kieleich]

Man macht keinen Spare beim RAID 1. Kannst du mit doppelt Redundanz laufen lassen.

Die Bitmap hat keinen Einfluss auf Speicher.

Du kannst auch mal ins mdadm --examine schaun. Evtl hat dein RAID 1 von 2018 noch ein kleines DATA Offset gehabt. Heute macht mdadm mal 100-200M weg für seinen eigenen Header, was dann für genau gar nichts genutzt wird. Bei zwei laufwerken im raid0 macht das auch wieder ein halbes Gigabyte weg

aber sehr wahrscheinlich ist es die genannte Dateisystem reserve. Es macht einfach kein Sinn mehr die Prozentual zu setzen.

 

[SFFox]

Schon mal danke für die vielen Rückmeldungen, ich denke der richtige Tipp ist schon dabei gewesen, reserved im file system wird wohl der Übeltäter sein. 👍

Kann es sein, dass der fehlende Speicher in dieser Bitmap hier steckt?

Laut @mae nicht, ich habe bitmap mal testweise deaktiviert und das sind nur ein paar MB als Cache und nicht die missing 400GB.

Nicht direkt was zum Thema, aber wenn die dritte Platte in deinem Raid1 einzig als Spare für nur dieses Raid1 dient, dann lass die direkt im Raid mitlaufen als dritte Platte. So sparst du dir das resilver im Falle eines Defekt und hast vielleicht sogar noch ne höhere Leseperformance, weil drei Platten.

Man macht keinen Spare beim RAID 1. Kannst du mit doppelt Redundanz laufen lassen.

Das muss ich mir noch mal überlegen. Das Raid1 ist für mich nur monatliches Backup meines Raid0 (und ggf. "auf Zuruf" wenn ich neue Daten auf dem Raid0 als sicherungswürdig betrachte), daher laufen die Platten nicht ständig, sondern sind brav im spindown bis zu ihrem Einsatz. Ein spare läuft für einen sync nicht an, sondern bleibt ausgeschaltet, was ja deutlich weniger Verschleiß für die Platte bedeutet. Ob ich die Bequemlichkeit des nachträglichen Sync damit aufwiege muss ich wohl mit meiner eigenen Präferenz aus machen.

Zudem gibt es noch eine externe 8TB luks crypted Platte an einem anderen Ort, die einmal im Quartal/Halbjahr gesynced wird. Das ist dann ein eingeschränktes Offsite Backup, denn der Sync selbst findet lokal statt.

Der Reiz von mehr Read Speed wäre reizvoll, wenn man so ein Backup mal wieder herstellen muss, denn von HDD auf SSD langweilen sich letztere doch sehr. Allerdings ist es so, dass es dann auch 3 Dateistreams geben muss, um davon zu profitieren. Die Frage ist: kann rsync das? Oder brauche ich dafür 3x händisch rsync von verschiedenen Teilordnern? Gibt es eine elegantere Lösung?

Wenn man's genau wissen will, vielleicht doch ohne -h. Und bitte auch die header-Zeile zeigen, und im Text beschreiben, was Du mit "freie Speicher" meinst. So habe ich erst einmal in der grossen Menge von gezeigten Daten raten muessen, was Du meinst.

Sorry, ich dachte wenn ich den verwendeten Command mit angebe ergibt sich das. Aber ja auf den ersten Blick für alle wäre eine Legende natürlich sinnvoller gewesen. 👍

Du kannst uebrigens mit

mdadm --grow --bitmap=none /dev/md0

die Bitmap ausschalten und solltest dann etwas mehr freien Speicher sehen, aber ich erwarte, dass es sich dabei um weniger als ein MB handelt. Siehe https://louwrentius.com/the-impact-of-the-mdadm-bitmap-on-raid-performance.html

Die Bitmap hat keinen Einfluss auf Speicher.

Getestet und wie von dir vermutet: ein insignificant Unterschied 👍 Hab danach bitmap wieder zurück auf "internal" gesetzt.

Du kannst auch mal ins mdadm --examine schaun. Evtl hat dein RAID 1 von 2018 noch ein kleines DATA Offset gehabt. Heute macht mdadm mal 100-200M weg für seinen eigenen Header, was dann für genau gar nichts genutzt wird. Bei zwei laufwerken im raid0 macht das auch wieder ein halbes Gigabyte weg

Hier ist das offset zwischen den HDDs/SSDs der beiden Raids in der Anzahl der sectors identisch und fällt somit nicht ins Gewicht. Das scheint der mdadm default zu sein 👍

Noch eine Ergaenzung: Die Bitmap ist ein Ding von md, und Du siehst die Groesse, die uebrigbleibt, bei df als 7,3T angegeben, bzw. in den "7813893120 blocks", die in /proc/mdstat angezeigt werden. Es liegt also einzig und allein am Filesystem, wenn da 400GB weniger Platz verfuegbar sind. Eine Moeglichkeit ist, dass beim Dateisystem auf md0 5% mehr Reserve eingestellt sind als beim Dateisystem auf md1. Ein anderes ist, dass da sehr viele kleine Dateien sind, und die Blockgroesse auf md0 groesser (dann wuerde ich aber auch einen hoeheren Wert fuer den belegten Speicher erwarten).

tune2fs liefert belastbare Antworten.

aber sehr wahrscheinlich ist es die genannte Dateisystem reserve. Es macht einfach kein Sinn mehr die Prozentual zu setzen.

Hier habt ihr drei ins Schwarze getroffen. tune2fs zeigt eine Menge reservierte Sektoren für das Raid md0 aber keine bei md1.
Mit "sudo tune2fs -m 0 /dev/md0" habe ich die reservierten Blöcke auf 0 gesetzt. Auf dem Laufwerk liegt ja auch nichts, was irgendwie systemkritisch ist.

Besten Dank für euer Wissen, wieder was gelernt 👍

 

[KillerCow]

Ob ich die Bequemlichkeit des nachträglichen Sync damit aufwiege

Während eines Resilver werden die restlichen Platten ggf. stärker beansprucht. Sind alle Platten gleich alt und gleich "abgenutzt", stehen die Chancen nicht schlecht, dass dir weitere Platten während des Resilver sterben. Dann hat dir die Spare nichts gebracht Und wenn du das Array sowieso schlafenlegst zwischendrin... dann spricht ja noch weniger dafür eine Spare vorzuhalten, damit die dann "frisch" ist.
Ok, die braucht ein bisschen Strom...

dass es dann auch 3 Dateistreams geben muss

Nicht zwingend. Soweit ich das noch im Kopf habe, ist md so schlau und ließt auch bei einem Raid1 angeforderte Blöcke parallel von mehreren Platten des Arrays (das machen tatsächlich nicht alle Raid1 Implementierungen). Wenn du also ne große Datei holst, sollten die zugehörigen Blöcke von mehreren Platten des Raids kommen und nicht nur von einer.
Ob parallele Streams das an der Stelle verbessern... bei HDDs... gute Frage🤔

Ergänzung (16. Juli 2025)

ah ok, damit mdadm das brauchbar über mehrere Platten verteilen kann bei nem Raid1, braucht man parallele Streams. Ist irgendwie auch klar... ich brauch Urlaub. Und rsync hat leider keine Parallelisierung im Bauch, soweit ich das sehe :/

 

[SFFox]

ah ok, damit mdadm das brauchbar über mehrere Platten verteilen kann bei nem Raid1, braucht man parallele Streams. Ist irgendwie auch klar... ich brauch Urlaub. Und rsync hat leider keine Parallelisierung im Bauch, soweit ich das sehe :/

Das hat meine bisherige Recherche dazu auch ergeben. GPT schlägt da diverse parallelisierungs-Möglichkeiten vor, um zu tricksen. Aber das wirklich automatisiert perfekt zu balancen ist wohl nicht so easy.
Vielleicht mache ich nachher dazu mal einen neuen Thread auf. Vielleicht hat jemand schon Gehirnschmalz in ein best practice gesteckt. Bis es eine Lösung gibt, bleibt das Spare brach liegen, denn falls die externe mal ausfällt kann das Spare auch Ersatz dafür werden 😂 Alles gammlige SMR Drives, aber damals sau günstig gewesen und aus externen Gehäusen gesalvaged

EDIT:
Scheinbar kann man den Speed für single transfers erhöhen, indem man den Read Ahead erhöht, weil der von mdadm scheinbar dann auch auf anderen Laufwerken ausgeführt werden kann. Müsste man alles mal testen und benchen...

EDIT2:
@KillerCow
Getestet bei Wiederbefüllung meines SSD Raids, nachdem ich alles jetzt auch luks encrypted habe:
Mit einer Erhöhung des Read Ahead auf 32MB steigt auch die single threaded Übertragungsrate.
Bei größeren Files gibt es dann peaks bis knapp über 300MB / Sekunde vom HDD Raid1 auf das SSD Raid0.
Um den höheren Speed konstanter zu halten habe ich trotzdem mehrere rsyncs parallel laufen lassen, read ahead alleine ist aber auch schon ein game changer.