Raid 5 ext4 größer als 16 TB

    • OMV 2.x
    • Raid 5 ext4 größer als 16 TB

      Ich habe folgendes Problem. Nachdem ich gestern meine 7. 3GB Festplatte im NAS verbaut und sie dem Raidverbund (Raid 5) zugefügt habe, wollte ich heute mit dem Befehl "resize2fs /dev/md127" das Dateisystem vergrößern.
      Leider passierte das nicht. Folgende Fehlermeldung kommt:

      Source Code

      1. resize2fs 1.42.5 (29-Jul-2012)
      2. resize2fs: Die neue Größe kann nicht mehr mit 32 Bits dargestellt werden
      Nach kurzem Googeln war mir klar das ich das Dateisystem auf 64 bit umstellen muss.
      Kann mir dazu bitte jemand schreiben wie ich das machen kann OHNE das das ich alle Daten vorher Sichern muss? Ich weis das ein Backup der wichtigen Daten sinnvoll ist, und das habe ich auch.

      Ich benutze Version 2.2.14 (Stone burner) / "Linux Server 3.2.0-4-amd64 #1 SMP Debian 3.2.93-1 x86_64"



      Danke schon mal im Voraus!
    • Wie gesagt, die wichtigen Daten sind gesichert. Hab ja eine Ausfallsicherheit bei Raid 5. Aber das steht ja hier nicht zum Thema.

      Also bleibt mir nix anderes übrig als den Raid zu löschen und neu einzurichten? Dein geposteter Thread ist leider in engl. und das war nicht meine Fremdsprache in der Schule sondern russisch :)
    • Hier das Ergebnis

      Source Code

      1. dumpe2fs 1.42.5 (29-Jul-2012)
      2. Filesystem volume name: Volume1
      3. Last mounted on: /media/0d944bd0-ae61-4d19-8eef-590c376244cd
      4. Filesystem UUID: 0d944bd0-ae61-4d19-8eef-590c376244cd
      5. Filesystem magic number: 0xEF53
      6. Filesystem revision #: 1 (dynamic)
      7. Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
      8. Filesystem flags: signed_directory_hash
      9. Default mount options: user_xattr acl
      10. Filesystem state: clean
      11. Errors behavior: Continue
      12. Filesystem OS type: Linux
      13. Inode count: 457834496
      14. Block count: 3662668800
      15. Reserved block count: 0
      16. Free blocks: 633981872
      17. Free inodes: 457830347
      18. First block: 0
      19. Block size: 4096
      20. Fragment size: 4096
      21. Reserved GDT blocks: 150
      22. Blocks per group: 32768
      23. Fragments per group: 32768
      24. Inodes per group: 4096
      25. Inode blocks per group: 256
      26. RAID stride: 128
      27. RAID stripe width: 256
      28. Flex block group size: 16
      29. Filesystem created: Fri Oct 17 17:20:02 2014
      30. Last mount time: Tue Nov 28 17:27:33 2017
      31. Last write time: Tue Nov 28 17:27:33 2017
      32. Mount count: 137
      33. Maximum mount count: -1
      34. Last checked: Fri Oct 17 17:20:02 2014
      35. Check interval: 0 (<none>)
      36. Lifetime writes: 21 TB
      37. Reserved blocks uid: 0 (user root)
      38. Reserved blocks gid: 0 (group root)
      39. First inode: 11
      40. Inode size: 256
      41. Required extra isize: 28
      42. Desired extra isize: 28
      43. Journal inode: 8
      44. Default directory hash: half_md4
      45. Directory Hash Seed: ad70e795-e3a6-4ce5-ade9-519e467d4a5f
      46. Journal backup: inode blocks
      47. Jounaleigenschaften: journal_incompat_revoke
      48. Journalgrösse: 128M
      49. Journal-Länge: 32768
      50. Journal-Sequenz: 0x0002f0b0
      51. Journal-Start: 1
      Display All
      Welches Dateisystem nimmt man denn heut zu Tage für Daten wenn nicht ext4 ? Das NAS Steht schon eine Weile und hat "nur" 2GB Ram.
    • Schnuffer wrote:

      Welches Dateisystem nimmt man denn heut zu Tage für Daten wenn nicht ext4 ?
      Keine Ahnung, was man so nimmt aber für mich überwiegen die Vorteile von sowohl ZFS als auch btrfs massiv (Datenintegrität, Snapshots, transparente Dateikompression, nicht irgendwo oberhalb des RAID- und Volume-Manager-Layers klebend sondern alles in einem seiend).

      Nur für btrfs braucht's recht aktuellen Kernel (unter 4.4 würde ich mich's nicht trauen) und ZFS mit nur 2 GB RAM könnte knapp werden. Wie auch immer, Deinem ext4 fehlt definitiv die 64-Bittigkeit also um irgendeine Umkopierorgie wirst Du nicht umhin kommen.

      Ach ja, besagte 32-bit-Beschränkung war auch der Hauptgrund, warum das letzte Neuaufsetzen von Storage mit ext4 so um 2010/2011 rum gewesen sein muß als die ersten Kunden anfingen, an der 16TB-Barriere zu knabbern. Damals mußte auf den Linux-Kisten dann halt noch XFS herhalten :)
    • Re,

      Schnuffer wrote:

      Dein geposteter Thread ist leider in engl. und das war nicht meine Fremdsprache in der Schule sondern russisch
      Oh ... noch ein "Ossi" *freu* :D

      Schnuffer wrote:

      Ich benutze Version 2.2.14 (Stone burner) / "Linux Server 3.2.0-4-amd64 #1 SMP Debian 3.2.93-1 x86_64"
      Oha ... da wäre ein OMV-Upgrade vllt. vorher fällig?

      Schnuffer wrote:

      Kann mir dazu bitte jemand schreiben wie ich das machen kann OHNE das das ich alle Daten vorher Sichern muss?
      Naja, es gibt kein "inline" Upgrade, d.h. du kannst es nicht mit einem Befehl innerhalb von EXT4 lösen. Daher musst du die Daten zwangsläuffig i'wo hin bewegen.

      Je nach Füllgrad könntest du vllt. so vorgehen:
      - auf dem jetzt freien Stück deines RAID-Verbundes eine neue Partition (mit 64bit!) erstellen (7,3 TiB)
      - Daten von deiner ersten (alten) Partiton auf die zweite (neue) Partition bewegen
      - dann die erste Partition verkleinern, die zweite vergrößern
      - das solange wiederholen, bis die erste (alte) Partition leer ist - und diese dann endgültig löschen / die neue (zweite) Partiton dann weiterverwenden

      Ansonsten bleiben dir ja nur die Möglichkeiten mit "Tabula rasa" (dein RAID-Verbund interessiert das Dateisystem leider herzlich wenig) - also enweder komplett neues EXT4 mit 64bit machen oder XFS einsetzen. Die Daten müssen dann natürlich auch zwischengespeichert werden ... aber wenn du DAS dann schon komplett neu machen möchtest, solltest du vorher auch OMV auf Version 3 heben ... ZFS mit 2GiB RAM würde ich nicht empfehlen.

      Sc0rp
    • Hallo Sc0rp,
      danke für deine Antwort.

      Ich finde leider keine Option eine neue Partition zu erstellen. Wenn ich unter "Dateisysteme" auf erstellen klicke, kann ich dort kein Laufwerk auswählen. Geht das vielleicht über putty besser?

      Hatte schon mal OMV 3 drauf, aber dann ständige Verbindungsabbrüche per NFS. Back to OMV 2 und alles ging wieder.

      Soll ich dann wieder ext4 machen oder XFS? Die Dateien sind recht groß. 10-100 GB pro Datei (Actioncam Videos)
      Images
      • raid.JPG

        31.02 kB, 774×265, viewed 83 times
      • partition.JPG

        32.55 kB, 1,138×145, viewed 84 times

      The post was edited 1 time, last by Schnuffer ().

    • Re,

      Schnuffer wrote:

      Soll ich dann wieder ext4 machen oder XFS? Die Dateien sind recht groß. 10-100 GB pro Datei (Actioncam Videos)
      EXT4 reicht, XFS würde ich nicht anfangen.
      Du musst halt deine neue EXT4-Partiton mit den gleichen Werten (siehe dem dumpe2fs) anlegen ... und das vermutlich via Console.

      Schnuffer wrote:

      Hatte schon mal OMV 3 drauf, aber dann ständige Verbindungsabbrüche per NFS.
      Ursachenforschung betrieben? Nur weil NFS auf einmal Abbrüche hat (was auch hochgradig ungewöhnlich ist) ... sollte man aktuellere Betriebssysteme nicht meiden.

      Sc0rp
    • Re,

      Schnuffer wrote:

      Muss ich dann beim neu Formatieren irgendetwas beachten? Bzw. gibt es dafür einen Consolenbefehl damit das Dateisystem dann auch wirklich 64 bit ist?
      das kommt darauf an, ob deine e3fsprogs schon entsprechend neu sind - dein dumpe2fs sieht zumindest nicht danach aus :(
      (siehe askubuntu.com/questions/779754…ion-beyond-the-16tb-limit)

      Also wäre vermutlich der XFS-Weg besser für dein (jetziges) Setup - obwohl ich dir immer noch dringender das OMV-Upgrade ans Herz legen würde (dann kommen auch u.A. neue e2fsprogs!), damit könntest du getrost auf ZFS gehen ...

      Für XFS müsstest du evtl. auch die Console bemühen:

      drdope wrote:

      In dem verwendetem Beispiel erstellen wir ein Raid5 aus 8 HDDs (--> sw=7) und 64k Stripsize (--> su=64k):mkfs.xfs -d su=64k,sw=7 /dev/sdc1
      In deinem Fall wäre das dann wahrscheinlich:
      mkfs.xfs -d su=128k,sw=3 /dev/md127 (ein vier Platten RAID5 mit 128k Stripesize)

      Oder für EXT4 wäre das in Etwa:
      (siehe gryzli.info/2015/02/26/calcula…t-performance-under-raid/)
      mkfs.ext4 -O 64bit -E stride=X,stripe-width=3*X /dev/md127 (X musst du dir selber ausrechnen, die RAID-Chunk-Size bekommst du von cat /proc/mdstat)

      Sc0rp

      The post was edited 1 time, last by Sc0rp ().

    • Re,

      Schnuffer wrote:

      ich dachte ZFS mit 2GB RAM ist nicht zu empfehlen, oder ist das bei OMV 3 anders?
      Das hat nix mit der OMV-Version zu tun.
      RAM-Cache wird unter Linux immer für File-Caching benutzt, je mehr du davon hast um so mehr wird gecached (zwischengespeichert) - so auch unter ZFS. Bei dir wird lediglich der übliche Performance-Gewinn beim Wechsel von EXT4 auf ZFS nicht spürbar sein, laufen müsste es trotzdem.

      Btw. wenig RAM ist sowieso nicht zu empfehlen :D, welchen nach zu stecken sollte ja kein Problem sein, oder?

      Sc0rp
    • Sc0rp wrote:

      RAM-Cache wird unter Linux immer für File-Caching benutzt, je mehr du davon hast um so mehr wird gecached (zwischengespeichert) - so auch unter ZFS. Bei dir wird lediglich der übliche Performance-Gewinn beim Wechsel von EXT4 auf ZFS nicht spürbar sein, laufen müsste es trotzdem.

      Naja, bei 'nem Gigabit Ethernet basierten NAS, das eh nur 'Cold Storage' vorhält, ist Performance eigentlich eh kein Thema. Man sollte aber mit häßlich wenig RAM dann zumindest eine Einstellung anpassen: zfs_arc_max -- siehe fibrevillage.com/storage/169-z…-set-and-monitor-on-linux (braucht dann vermutlich ein 'initramfs -U' hinterher, damit das Reboot-fest wird).

      Mit 'Cold Data' kann man den Wert ruhig recht minimal setzen, weil's eh egal ist.
    • Sc0rp wrote:

      Oder für EXT4 wäre das in Etwa:

      (siehe gryzli.info/2015/02/26/calcula…t-performance-under-raid/)
      mkfs.ext4 -O 64bit -E stride=X,stripe-width=3*X /dev/md127 (X musst du dir selber ausrechnen, die RAID-Chunk-Size bekommst du von cat /proc/mdstat)
      Ich habe aktuell 7 HDD's verbaut. Platz ist für 10. Wenn ich jetzt mit "stripe-width=6*X" (was ja in meinem Fall das richtige wäre) Formatiere, was passiert dann wenn ich noch eine HDD verbaue? Dann müsste es doch "stripe-width=7*X" sein. Kann man das im nachhinein ändern?
    • Re,

      Schnuffer wrote:

      Ich habe aktuell 7 HDD's verbaut. Platz ist für 10. Wenn ich jetzt mit "stripe-width=6*X" (was ja in meinem Fall das richtige wäre)
      Japp.


      Schnuffer wrote:

      was passiert dann wenn ich noch eine HDD verbaue? Dann müsste es doch "stripe-width=7*X" sein. Kann man das im nachhinein ändern?
      Gute Frage. Ich weiß nicht, ob man das mit tune2fs später ändern kann, aber die "stripe-width" ist nicht so wichtig wie "stride", "stride" muss passen, ansonsten erleidet dein Verbund einen erheblichen Performanceverlust ...

      Laut dem man für tune2fs kann man später auch noch die "extended options" anpassen ...

      Sc0rp
    • Sc0rp wrote:

      "stride" muss passen, ansonsten erleidet dein Verbund einen erheblichen Performanceverlust ...
      Auf was basieren eigentlich diese Anekdoten? Immer, wenn ich gucke, finde ich als Primärquelle nur Zeugs von Mailinglisten von vor gefühlt 100 Jahren, was jetzt auch wiederum nicht so wahnsinnig verwunderlich ist angesichts dessen, was es bedeutet, RAID-5 mit ext4 in diesem Jahrzehnt zu kombinieren (und dann allen Ernstes auch noch LVM reinzumischen, was ja auch viele gerne tun).

      Auf die Schnelle das da gefunden: admin-magazin.de/Das-Heft/2011…AID-optimal-konfigurieren -- das ist doch alles nur ein Witz? Benchmark-Werkzeuge eingesetzt, die alles mögliche testen aber nicht das, was sie sollen, Anwendungsszenarien betrachtet, die aberwitzig sind (Datenbanken auf 'nem RAID-5? Nicht wirklich, oder?) und anstatt mit "Wir wissen's doch auch nicht und das ist alles nur traurig" am Ende mit Empfehlungen abschließen. Zieht sich aber wie ein roter Faden durch die "RAID-5-Situation" in Linux...
    • Ich habe jetzt alles gesichert, das Dateisystem ausgehangen und den Raidverbund entfernt.
      OMV 3 installiert und jetzt erstelle ich den Raidverbund neu (dauert noch ca. 8 Stunden)
      RAM werde ich nicht aufrüsten, denn der hat bis jetzt auch gereicht. Ist im übrigen ein AMD Athlon II X2 240 Prozessor, also schon etwas älter und mit DDR2 RAM

      Da der Kernel jetzt 4.9.0 ist, könnte ich doch auch btrfs als FS nehmen ??? Ich nutze das NAS nur als Datengrab. Keine Datenbank oder sowas laufen da drauf.

      Auf der anderen Seite bin ich ja mit ext4 bis jetzt auch immer gut gefahren. Habe ja auch schon von 4 HDD's in einerschritten bis auf 6 HDD's aufgerüstet. Mein Problem war ja nur das ich mit der 7. HDD nun über die 16TB gekommen bin, und somit ein "Problem" hatte. Da ich ja jetzt alles neu mache, würde es sich zwar anbieten auf ein aktuelles FS zu wechseln, aber warum? Never change a runnig System. Ich mache keine Snapshots. Ich mache eigentlich garnix weiter außer Daten auf das NAS kopieren und mir im laufe der Zeit mal am TV oder Tablet anzuschauen mit der Familie.