Arny80Hexa
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
Wollte soeben mein bestehendes RIAD6 (6x4TB) auf 7x4TB erweitern. Das Reshaping ist eben fertig geworden und nun wollte ich wie im Wiki beschrieben (software-raid (Abschnitt „RAID-erweitern“)) das Dateisystem auf die volle Größe von 20TB erweitern. Tja Pustekuchen, denn der resize2fs Befehl wird direkt mit einem unschönen Fehler quittiert (Letzte Zeile): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51 | homeserver boss # cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid6 sdh1[7] sdg1[6] sdf1[5] sdc1[0] sdb1[4] sde1[3] sdd1[1]
19534410240 blocks super 1.2 level 6, 512k chunk, algorithm 2 [7/7] [UUUUUUU]
unused devices: <none>
homeserver boss # mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 3906882048 (3725.89 GiB 4000.65 GB)
Raid Devices : 7
Total Devices : 7
Persistence : Superblock is persistent
Update Time : Wed Nov 11 20:18:54 2015
State : clean
Active Devices : 7
Working Devices : 7
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : homeserver-linux:0
UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Events : 2467483
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 65 2 active sync /dev/sde1
4 8 17 3 active sync /dev/sdb1
5 8 81 4 active sync /dev/sdf1
6 8 97 5 active sync /dev/sdg1
7 8 113 6 active sync /dev/sdh1
homeserver boss # umount /dev/md0
homeserver boss # fsck.ext4 -f /dev/md0
e2fsck 1.42.9 (4-Feb-2014)
Durchgang 1: Prüfe Inodes, Blocks und Größen
Durchgang 2: Prüfe die Verzeichnisstruktur
Durchgang 3: Prüfe Verzeichnis-Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe die zusammengefasste Gruppeninformation
/dev/md0: 585013/488361984 Dateien (1.3% nicht zusammenhängend), 3705294040/3906882048 Blöcke
homeserver boss # resize2fs /dev/md0
resize2fs 1.42.9 (4-Feb-2014)
resize2fs: Die neue Größe kann nicht mehr mit 32 Bits dargestellt werden
|
Zunächst war ich sehr irritiert, da ich der Auffassung war, das ext4 weitaus größere Datenträger verwalten kann. Nachdem ich dann den ausgegebenen Fehler in Englisch gefunden habe ("too big to be expressed in 32 bits using a blocksize of") und danach entsprechend googeln konnte, bin ich auch auf das Problem gestoßen. Zwar kann ext4 bis 1EiB verwalten aber resize2fs arbeitet leider nur mit 32Bit und somit ist bei 16TB schluss. Ich hatte dann auch wenigstens irgendwie einen Beitrag http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/ im Netz gefunden auf dem einer das mal durchgetestet hat. Mit dem traurigem Ergebnis, dass man zwar mit der dev-Version von resize2fs Laufwerke mit über 16TB anlegen kann, aber eben nicht, wie in meinem Fall, ein bestehendes System auf über 16TB erweitern. ☹ Allerdings ist der Beitrag auch schon von 2011 und die resize2fs Version ist bei mir heute aktueller als die Beta in dem Beitrag damals. Also hoffe ich dass sich da in der Zwischenzeit was getan hat! Ich meine, wie schaffen das die Hersteller von Qnap und Co.? Da ist am Ende auch nur nen Linux-SW Raid am laufen (Hab betrieblich solche Kisten mit bis zu 8x4TB im Einsatz gehabt). Auch ein Storage mit OpenE hatten wir damals im Betrieb laufen, was deutlich über 16TB hatte. Ich hoffe sehr, dass ihr eine Lösung für mich habt, die nicht in die Richtung alá "neu machen" geht. Denn Das Raid ist mit 16TB rand voll und den Platz zum Auslagern hab ich natürlich nicht mal eben rum stehen. Irgendwie muss das doch gehen!? Lieben Dank schon mal an alle die bis hier gelesen haben und sich Gedanken machen!
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Ist ein bekanntes Problem...
Irgendwie muss das doch gehen!?
Man kann ext4 nach btrfs konvertieren. Ob du das jetzt unbedingt willst, ist die andere Frage. Ansonsten das RAID auf maximal 16TB schrumpfen, dahinter neue Partition mit zweitem RAID und zweitem Dateisystem und den Rest dann eben über geschickte Datenhaltung regeln. Ansonsten wirds ziemlich eklig, wenn du es riskieren willst und für den Vorgang auf Redundanz verzichtest, kannst du zwei Platten aus dem RAID6 werfen, mit diesen zwei Platten ein neues RAID6 erstellen (dem 2 Platten fehlen), darauf ein Dateisystem erstellen (ist dann 2x4TB groß) - das kann dann auch ext4 sein denn man kann bei mkfs.ext4 angeben daß es 64bit sein soll - dann 2 Platten Daten rüberschieben, Quelldateisystem und Quellraid um 2 Platten schrumpfen, 2 Platten raus, ins andere RAID rein das entsprechend wachsen lassen und entsprechend weiter Daten rüberkopieren. Langwieriger Vorgang und saugefährlich, weil du während der gesamten Zeit (und den notwendigen Reshapes dabei die ewig dauern und auch schiefgehen können) keinerlei Redundanz hast.
|
Arny80Hexa
(Themenstarter)
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
frostschutz schrieb: Ist ein bekanntes Problem...
Schade das es anscheinend immer noch keine praktikable Lösung dafür gibt. Ich meine, sowas ist ja heute keine Seltenheit oder Besonderheit mehr!? Irgendwie muss das doch gehen!?
Man kann ext4 nach btrfs konvertieren. Ob du das jetzt unbedingt willst, ist die andere Frage.
Kannst du kurz die Vor- und Nachteile auf den Tisch legen? Oder hast du einen Link? Ich hatte damals sogar mit dem Gedanken gespielt direkt ein btrfs draus zu machen. Da mir das aber alles noch zu neu und unerprobt war, bin ich dann doch bei den etablierten Sachen geblieben. Wollte halt auch kein Risiko eingehen.
Ansonsten das RAID auf maximal 16TB schrumpfen, dahinter neue Partition mit zweitem RAID und zweitem Dateisystem und den Rest dann eben über geschickte Datenhaltung regeln.
Das ist eigentlich wirklich der letzte Strohhalm, den ich greifen möchte, da ich eigentlich das gesamte Archiv extra für ein großes Laufwerk ausgelegt hatte. Konnte ja nicht ahnen, dass mir da mal ein winziges aber essenzielles Tool einen Strich durch die Rechnung machen wird.
Ansonsten wirds ziemlich eklig, wenn du es riskieren willst und für den Vorgang auf Redundanz verzichtest, kannst du zwei Platten aus dem RAID6 werfen, mit diesen zwei Platten ein neues RAID6 erstellen (dem 2 Platten fehlen), darauf ein Dateisystem erstellen (ist dann 2x4TB groß) - das kann dann auch ext4 sein denn man kann bei mkfs.ext4 angeben daß es 64bit sein soll - dann 2 Platten Daten rüberschieben, Quelldateisystem und Quellraid um 2 Platten schrumpfen, 2 Platten raus, ins andere RAID rein das entsprechend wachsen lassen und entsprechend weiter Daten rüberkopieren. Langwieriger Vorgang und saugefährlich, weil du während der gesamten Zeit (und den notwendigen Reshapes dabei die ewig dauern und auch schiefgehen können) keinerlei Redundanz hast.
Ich würde für den Zweck sogar noch mal eine oder zwei 4TB Platten kaufen (mehr kann ich nicht anschließen, da ich "nur" 10-SATA-Anschlüsse auf dem Board habe und an einem ja noch die SSD mit dem Betriebssystem hängt). Ich muss hier noch mal kurz nachhaken, ob ich das richtig verstanden habe:
Ich kann also ein RAID6 von Anfang an (auch weniger als 16TB) auf 64Bit(-Architektur) erstellen und dann komme ich später mit resize2fs auch über die 16TB hinaus? Warum macht man das dann Heutzutage nicht sowieso? Wo ist der Haken? P.s.: (Kleiner Verbesserungsvorschlag) Eine entsprechende Anmerkung bzw. Hinweis im Wiki wäre vielleicht auch mal sinnvoll, damit nicht noch mehr Leute in diese blöde Falle tappen...?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Ich kann zu btrfs nichts weiter sagen, ich habe mich da auch noch nicht dran getraut. Arny80Hexa schrieb: Ich würde für den Zweck sogar noch mal eine oder zwei 4TB Platten kaufen (mehr kann ich nicht anschließen, da ich "nur" 10-SATA-Anschlüsse auf dem Board habe und an einem ja noch die SSD mit dem Betriebssystem hängt).
Mit mehr Platten (oder alternativ mehr Platz frei) kannst du es natürlich mit Redundanz auf beiden Seiten machen, bleiben nur die störrischen Grow-Vorgänge. 😉
Ich kann also eine RAID6 von Anfang an (auch weniger als 16TB) auf 64Bit(-Architektur) erstellen und dann komme ich später mit resize2fs auch über die 16TB hinaus?
Nicht RAID6, das Medium ist ja wurst, sondern EXT4 ist entscheidend, also mkfs.ext4 -O 64bit . Möglicherweise braucht es noch weitere Optionen, z.B. -T huge oder sowas wenns primär z.B. um Filmdateien geht die sehr groß sind. -T huge wird defaultmäßig genommen wenn du mit 16TB+ anfängst... muss deswegen nicht sinnvoll sein aber da man einige Sachen nur bei mkfs bestimmen kann wär das der Zeitpunkt sich da mal reinzufuchsen was es so gibt und was man davon brauchen will. Oder du nimmst ein anderes Dateisystem das keine Probleme mit 16TB hat, zum Beispiel XFS oder sowas (wenns dir nichts ausmacht daß man XFS nicht ohne weiteres kleiner machen kann).
Warum macht man das dann Heutzutage nicht sowieso? Wo ist der Haken?
Fehlende Rückwärtskompatibilität? Keine Ahnung, wirklich. Performanztests habe ich keine gefahren. Hier mal ext4 von 4T jeweils verdoppelt bis auf 32T: # truncate -s 4T foobar.img
# losetup --find --show foobar.img
/dev/loop0
# mkfs.ext4 -O 64bit /dev/loop0
mke2fs 1.42.13 (17-May-2015)
Discarding device blocks: done
Creating filesystem with 1073741824 4k blocks and 134217728 inodes
Filesystem UUID: 152cf248-b16f-4f3b-b63f-b3d697bdfd4e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# losetup -D
# truncate -s 8T foobar.img
# losetup --find --show foobar.img
/dev/loop0
# resize2fs /dev/loop0
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/loop0 to 2147483648 (4k) blocks.
The filesystem on /dev/loop0 is now 2147483648 (4k) blocks long.
# losetup -D
# truncate -s 16T foobar.img
# losetup --find --show foobar.img
/dev/loop0
# resize2fs /dev/loop0
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/loop0 to 4294967296 (4k) blocks.
The filesystem on /dev/loop0 is now 4294967296 (4k) blocks long.
# losetup -D
# truncate -s 32T foobar.img
# losetup --find --show foobar.img
/dev/loop0
# resize2fs /dev/loop0
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/loop0 to 8589934592 (4k) blocks.
The filesystem on /dev/loop0 is now 8589934592 (4k) blocks long.
Bei diesem Beispiel eines leeren Dateisystems hat das also geklappt. Wobei ich sagen muss, daß das ziemlich lange gedauert hat, dafür daß es leer und auf einer ramdisk war. Wieviel RAM hast du denn in der Kiste? fsck.ext4 braucht auch ganz schön viel ...
|
Arny80Hexa
(Themenstarter)
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
frostschutz schrieb:
Vorab erstmal riesen Dank für deine Hilfe! Ich kann zu btrfs nichts weiter sagen, ich habe mich da auch noch nicht dran getraut.
Dann sind wir uns hier ja schon mal einig.
Mit mehr Platten (oder alternativ mehr Platz frei) kannst du es natürlich mit Redundanz auf beiden Seiten machen, bleiben nur die störrischen Grow-Vorgänge. 😉
Wieso Störrisch? Hab damals mit 3x4TB im Raid 5 angefangen. Dann auf 4x4TB Raid5 gegrowt. Dann zwei weitere 4TB Platten rein und auf Raid6 Gegrowt. Der Grow dauert nun zwar mittlerweile rund 24Stunden, hat aber bisher keine Probleme gemacht!? Ich kann also eine RAID6 von Anfang an (auch weniger als 16TB) auf 64Bit(-Architektur) erstellen und dann komme ich später mit resize2fs auch über die 16TB hinaus?
Nicht RAID6, das Medium ist ja wurst, sondern EXT4 ist entscheidend, also mkfs.ext4 -O 64bit . Möglicherweise braucht es noch weitere Optionen, z.B. -T huge oder sowas wenns primär z.B. um Filmdateien geht die sehr groß sind. -T huge wird defaultmäßig genommen wenn du mit 16TB+ anfängst... muss deswegen nicht sinnvoll sein aber da man einige Sachen nur bei mkfs bestimmen kann wär das der Zeitpunkt sich da mal reinzufuchsen was es so gibt und was man davon brauchen will.
Vielleicht mach -T huge sogar sinn (kannte ich noch nicht). Platzmäßig (also was am meisten Speicherplatz braicht) ist der prozentuale Löwenanteil der Datein tatsächlich jenseits von 3GB. Allerdings liegen hier auch viele nfo's und Bilder. Wenn ich also den Prozentualen Anteil nur anhand der Dateianzahl messe, dann ist die Mehrheit der Dateien wahrscheinlich unter 5MB. Davon ab hatte ich tatsächlich immer das Gefühl, dass das Raid (dafür dass hier 4 Platten Gleichzeitig lesen und schreiben) eher langsam ist. Da es aber immer noch eine Art Archiv ist, also alles nur abgelegt und nur neues hinzu kommt, war das nicht soooo tragisch.
Oder du nimmst ein anderes Dateisystem das keine Probleme mit 16TB hat, zum Beispiel XFS oder sowas (wenns dir nichts ausmacht daß man XFS nicht ohne weiteres kleiner machen kann).
Auch das stand damals zur Auswahl und auch hier hatte ich mich aus irgendwelchen Gründen dagegen entschieden. Und in der Situation jetzt zum Beispiel bin ich ganz froh, dass ext4 verkleinern kann! 😉 Und auch wenn ich mit xsf jetzt dieses Problem nicht hätte, so möchte ich nicht ausschließen, dass ich nicht irgendwann mal in die Situation komme, wo ich das Raid shrinken muss.
Und da fällt mir auch schon sofort ein, wann das sein wird: Der Plan ist in absehbarer Zeit auf 8TB-Platten umzustellen (Wenn die ausgereifter und preisgünstiger sind). Da mir an meinem Rechner die SATA-Ports irgendwann ausgehen. Und hier würde ich dann auch erst mit wenigen 8TB-Platten anfangen. Daten aus dem alten Raid ins neue ziehen. Altes Raid schrumpfen und dann das neue 8-Platten-Raid erweitern. Wir sehen: XFS würde mich auch wieder einschränken. Fehlende Rückwärtskompatibilität? Keine Ahnung, wirklich. Performanztests habe ich keine gefahren.
Wie gesagt, ein Hinweis im RAID-Artikel im Wiki wäre zumindest hilfreich gewesen.
Hier mal ext4 von 4T jeweils verdoppelt bis auf 32T:
Bei diesem Beispiel eines leeren Dateisystems hat das also geklappt. Wobei ich sagen muss, daß das ziemlich lange gedauert hat, dafür daß es leer und auf einer ramdisk war.
Wie gesagt, der letzte reshape von 6 auf 7 Platten RIAD6 lief jetzt etwa 24h. Aber zeit ist kein Problem für mich. ☺
Wieviel RAM hast du denn in der Kiste? fsck.ext4 braucht auch ganz schön viel ...
Aktuell sind es leider noch 16GB. Wollte letztens schon auf 32GB aufrüsten, aber den Speicher gibt es nicht mehr... 😐 Genügen 16GB? Also jetzt noch mal zu meiner Idee, die sich hier gerade raus kristallisiert:
eine weitere 4TB Platte besorgen die 7. HHD aus dem RAID6 wieder raus schmeißen (muss ich auch erstmal schauen wie das geht. Link?) die beiden HHD's zu einem RAID1 verbinden (so weit mir bekannt kann ich aus einem Raid1 später auch ein RAID5 und RAID6 machen, oder?) ext4 mit 64-Bit auf das RAID1 Daten vom alten Raid in's neue kopieren
und dann immer wieder Daten kopieren, Schrumpfen, Platte vom alten ins Neue Raid wechseln und dieses growen.
Ich muss nur zwischenzeitlich dann doch mal wenigstens eine Redundanz aus dem alten Raid ziehen, weil ich sonst ja beim neuen Raid keine Redundanz hätte (Beim Wechsel von 2HDD-RAID1 auf RAID5 (mit 4 Statt 3 Platten) erscheint es mir sinnvoll). So in etwa war der Plan dann auch beim Umzug auf ein Raid mit 8TB-Platten. Fehler in der Denkweise mögen mir verziehen, ist schon wieder ziemlich spät für so komplexe Sachen. 🙄
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Arny80Hexa schrieb: Wieso Störrisch?
Wenn du ins Archive der Linux RAID Mailingliste schaust, fast alle Threads in jüngerer Vergangenheit haben RAID6 Grow steckengeblieben/schiefgegangen als Thema. Da gibts irgendein Problem zur Zeit das noch nicht behoben ist.
Und da fällt mir auch schon sofort ein, wann das sein wird: Der Plan ist in absehbarer Zeit auf 8TB-Platten umzustellen (Wenn die ausgereifter und preisgünstiger sind). Da mir an meinem Rechner die SATA-Ports irgendwann ausgehen. Und hier würde ich dann auch erst mit wenigen 8TB-Platten anfangen. Daten aus dem alten Raid ins neue ziehen. Altes Raid schrumpfen und dann das neue 8-Platten-Raid erweitern. Wir sehen: XFS würde mich auch wieder einschränken.
Da würde ich mir trotzdem eine Möglichkeit suchen die Umstellung zu machen ohne dabei das bestehende RAID zerstören zu müssen. Selbst wenn du dann alles über Gigabit auf einen anderen Rechner jockeln musst. Denn das ist niemals ganz ungefährlich.
Wie gesagt, ein Hinweis im RAID-Artikel im Wiki wäre zumindest hilfreich gewesen.
Schreib einen Hinweis rein, sowohl im RAID als auch im EXT4-Artikel, das 16TB Limit wird da glaub ich gar nicht erwähnt, die Zielgruppe von Ubuntu kam bislang ja auch nur in Ausnahmefälle in solche Regionen, aber jetzt mit 8TB pro Platte ist das nicht mehr weit...
Aktuell sind es leider noch 16GB. Wollte letztens schon auf 32GB aufrüsten, aber den Speicher gibt es nicht mehr... 😐 Genügen 16GB?
Ich hoffs. 😉 Ich habe keine so großen ext-Dateisysteme.
Poste mal die aktuelle Situation mit mdadm --detail /dev/md*, mdadm --examine /dev/sd*, und die Speicherplatzbelegung wie sie df -h anzeigt.
Mach gleich als RAID6, das ist einfacher.
|
Arny80Hexa
(Themenstarter)
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
frostschutz schrieb: Wenn du ins Archive der Linux RAID Mailingliste schaust, fast alle Threads in jüngerer Vergangenheit haben RAID6 Grow steckengeblieben/schiefgegangen als Thema.
Da gibts irgendein Problem zur Zeit das noch nicht behoben ist.
Danke für den Hinweis, aber da werde ich wohl nicht drum rum kommen. Außerdem lief bisher ja alles glatt bei mir. Und ansonsten sehen wir optimistisch in die Zukunft und hoffen das beste und versuchen die Anzahl der Grows zu reduzieren. ☺
Gibts eine Bestimmte Situation wo die Probleme auftreten, die man vermeiden sollte? Du sagtest der Fehler tritt beim RAID6-Growen auf!? Vielleicht also eine Idee bis zum Schluss auf RAID5 zu fahren und dann beim letzten Grow erst auf Raid6 umzustellen?
Da würde ich mir trotzdem eine Möglichkeit suchen die Umstellung zu machen ohne dabei das bestehende RAID zerstören zu müssen. Selbst wenn du dann alles über Gigabit auf einen anderen Rechner jockeln musst.
Denn das ist niemals ganz ungefährlich.
Ist es doch nie, wenn man an sowas rumfuhrwerkt. Darum habe ich die Nacht auch noch mal gegrübelt und meinen Plan etwas abgewandelt:
Ich hab hier noch ein paar externe Platten rumliegen. Da werde ich schon mal 4TB an Daten auslagern. Dann kann ich das bestehende Raid gleich schon mal um 2 Platten (8TB) Schrumpfen. Dann die Daten wieder auf die einzelnen Platten (ohne Raid) auslagern. Wieder 2 Platten aus dem Raid ziehen und so weiter.
Das ist zwar mehr Kopierarbeit, aber das überstehen die Platten schon (sind alle noch recht neu und der Rechner lief auch nur, wenn in Benutzung). Das hat für mich am Ende mehrere Vorteile:
Ich brauche keine zusätzliche Platte kaufen Ich habe zum Schluss 4 leere 4TB Platten übrig und kann direkt ein RAID6 bauen Damit veringere ich auch die Anzahl der Grows, da ich mit jedem Schritt gleich um 8TB (2 Platten) Growen kann. Ich muss in der Zwischenzeit kein RAID ohne Paritäten betreiben. Wenn eine von den einzelnen Platten zwischendurch den Geist auf gibt (wovon ich jetzt mal nicht aus gehe), sind schlimmstenfalls "nur" 4TB an Daten verloren, nicht gleich die Daten des gesamten Raids Es ist für mich nachher ein bisschen übersichtlicher da ich die Platten dann auch Physikalisch aus den Rechner ziehe und nachher nicht mit den ganzen Laufwerkszuordnungen durcheinander komme und noch gar eine Falsche Platte lösche / überschreibe, ect.
Wie gesagt, ein Hinweis im RAID-Artikel im Wiki wäre zumindest hilfreich gewesen.
Schreib einen Hinweis rein, sowohl im RAID als auch im EXT4-Artikel, das 16TB Limit wird da glaub ich gar nicht erwähnt, die Zielgruppe von Ubuntu kam bislang ja auch nur in Ausnahmefälle in solche Regionen, aber jetzt mit 8TB pro Platte ist das nicht mehr weit...
Selbst mit den mittlerweile erschwinglichen 4TB Platten (150€/Stk.) ist es, wie du siehst problemlos möglich.
Na ja, ich trau mich nicht recht da im Wiki was anzufassen. Ich hab zwar durch 4 Jahre intensive Admin-Tätigkeit überwiegend im Linux-Bereich schon ganz ordentliche Kenntnisse angesammelt, aber dennoch bei Weitem nicht das Wissen wie der ein oder andere Linux-Guru hier auf Ubuntuusers, der schon 10,15 oder 20 Jahre mit Linux arbeitet. Poste mal die aktuelle Situation mit mdadm --detail /dev/md*, mdadm --examine /dev/sd*, und die Speicherplatzbelegung wie sie df -h anzeigt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 | boss@homeserver ~ $ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda6 227G 75G 141G 35% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
udev 7,7G 4,0K 7,7G 1% /dev
tmpfs 1,6G 1,7M 1,6G 1% /run
none 5,0M 0 5,0M 0% /run/lock
none 7,7G 251M 7,5G 4% /run/shm
none 100M 20K 100M 1% /run/user
/dev/sda5 945M 87M 794M 10% /boot
/dev/md0 15T 14T 39G 100% /media/data
/home/boss/.Private 227G 75G 141G 35% /home/boss
boss@homeserver ~ $ df
Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda6 237977232 78583092 147282524 35% /
none 4 0 4 0% /sys/fs/cgroup
udev 8030968 4 8030964 1% /dev
tmpfs 1609352 1740 1607612 1% /run
none 5120 0 5120 0% /run/lock
none 8046740 256248 7790492 4% /run/shm
none 102400 20 102380 1% /run/user
/dev/sda5 967320 88200 812768 10% /boot
/dev/md0 15504259492 14682223208 40643496 100% /media/data
/home/boss/.Private 237977232 78583092 147282524 35% /home/boss
homeserver boss # mdadm --detail /dev/md*
mdadm: /dev/md does not appear to be an md device
/dev/md0:
Version : 1.2
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 3906882048 (3725.89 GiB 4000.65 GB)
Raid Devices : 7
Total Devices : 7
Persistence : Superblock is persistent
Update Time : Fri Nov 13 14:04:38 2015
State : clean
Active Devices : 7
Working Devices : 7
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : homeserver-linux:0
UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Events : 2467485
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 65 2 active sync /dev/sde1
4 8 17 3 active sync /dev/sdb1
5 8 81 4 active sync /dev/sdf1
6 8 97 5 active sync /dev/sdg1
7 8 113 6 active sync /dev/sdh1
|
Und noch die Platten einzeln:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236 | homeserver boss # mdadm --examine /dev/sd*
/dev/sda:
MBR Magic : aa55
Partition[0] : 204800 sectors at 2048 (type 07)
Partition[1] : 458752000 sectors at 206848 (type 07)
Partition[2] : 32000000 sectors at 458958848 (type 82)
Partition[3] : 485810178 sectors at 490960894 (type 05)
/dev/sda1:
MBR Magic : aa55
Partition[0] : 1836016416 sectors at 1936269394 (type 4f)
Partition[1] : 544437093 sectors at 1917848077 (type 73)
Partition[2] : 544175136 sectors at 1818575915 (type 2b)
Partition[3] : 54974 sectors at 2844524554 (type 61)
/dev/sda2:
MBR Magic : aa55
Partition[0] : 1836018464 sectors at 1380404564 (type 0a)
Partition[1] : 1953723749 sectors at 1309281536 (type 69)
Partition[2] : 1953251627 sectors at 1735554131 (type 6d)
Partition[3] : 55233 sectors at 2978742282 (type 66)
mdadm: No md superblock detected on /dev/sda3.
/dev/sda4:
MBR Magic : aa55
Partition[0] : 1998848 sectors at 2 (type 83)
Partition[1] : 483811328 sectors at 1998850 (type 05)
mdadm: No md superblock detected on /dev/sda5.
mdadm: No md superblock detected on /dev/sda6.
/dev/sdb:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 01af322a:8db97090:84b67f6a:4a3887f2
Update Time : Fri Nov 13 14:05:31 2015
Checksum : 6eb398cd - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAAAAA ('A' == active, '.' == missing)
/dev/sdc:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 38afe37c:c3eea66a:37bdbbda:fa9cad30
Update Time : Fri Nov 13 14:05:31 2015
Checksum : 49fd3999 - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAAAAA ('A' == active, '.' == missing)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 61986584:b825a4ea:5058410d:c975fd01
Update Time : Fri Nov 13 14:05:31 2015
Checksum : d551cd9f - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAAAAA ('A' == active, '.' == missing)
/dev/sde:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 21c00c05:2aea97eb:4e0944c7:84c1f278
Update Time : Fri Nov 13 14:05:31 2015
Checksum : 87e4b68d - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAAAAA ('A' == active, '.' == missing)
/dev/sdf:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 6382f071:eaafa5ba:5db388a5:d4401c9b
Update Time : Fri Nov 13 14:05:31 2015
Checksum : c44467f0 - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 4
Array State : AAAAAAA ('A' == active, '.' == missing)
/dev/sdg:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 26b2f9ac:a2f172f4:6eda257e:a97375ec
Update Time : Fri Nov 13 14:05:31 2015
Checksum : 63113353 - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 5
Array State : AAAAAAA ('A' == active, '.' == missing)
/dev/sdh:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c020a471:95195dfa:5efa437c:9a7d9d9f
Name : homeserver-linux:0
Creation Time : Sun Mar 16 11:09:29 2014
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 7813764785 (3725.89 GiB 4000.65 GB)
Array Size : 19534410240 (18629.47 GiB 20003.24 GB)
Used Dev Size : 7813764096 (3725.89 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 7cd95722:0bcb72d8:1091fc84:12336be3
Update Time : Fri Nov 13 14:05:31 2015
Checksum : ba3baa1d - correct
Events : 2467485
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 6
Array State : AAAAAAA ('A' == active, '.' == missing)
|
Mach gleich als RAID6, das ist einfacher.
Jupp, wie oben geschrieben fange ich gleich mit 4x4TB RAID6 an. P.s. Nochmals riesen Dank für deine umfangreiche Hilfe!
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Arny80Hexa schrieb: Vielleicht also eine Idee bis zum Schluss auf RAID5 zu fahren und dann beim letzten Grow erst auf Raid6 umzustellen?
Das würde ich jetzt auch nicht unbedingt machen. mdadm hat da vor relativ kurzer Zeit ein größeres Data-Offset eingeführt (früher 1MB, heute 128MB), um dieses bei einem Grow etappenweise reduzieren zu können. Dadurch fällt die Notwendigkeit für ein Backup-File weg, das sonst (zumindest ganz am Anfang) nötig ist um den Grow-Vorgang absturzsicher zu machen. Du könntest auf dieses Feature verzichten indem du beim mdadm --create direkt --data-offset=1M angibst und dann die Grows eben explizit mit --backup-file=/mnt/irgendwo/datei anstößt.
Wenn eine von den einzelnen Platten zwischendurch den Geist auf gibt (wovon ich jetzt mal nicht aus gehe), sind schlimmstenfalls "nur" 4TB an Daten verloren, nicht gleich die Daten des gesamten Raids
Wenns da irgendwelche Zweifel gibt, vorher schauen daß die SMART-Daten OK sind und ein smartctl -t long durchläuft.
Na ja, ich trau mich nicht recht da im Wiki was anzufassen.
Trau dich! 😛
dennoch bei Weitem nicht das Wissen wie der ein oder andere Linux-Guru hier auf Ubuntuusers
Mir sind hier noch keine Gurus über den Weg gelaufen. Das sind alles ganz normale, verrückte und bekloppte Menschen wie du und ich.
Mach gleich als RAID6, das ist einfacher.
Jupp, wie oben geschrieben fange ich gleich mit 4x4TB RAID6 an. P.s. Nochmals riesen Dank für deine umfangreiche Hilfe!
Das war mehr so gedacht für RAID6 auf 2 Platten (mit 2 Platten fehlend), aber deine Idee ist auch gut. Das ganze auf beiden Seiten zwar mit RAID6, aber einfacher Parity (also eine Platte fehlend) durchzuführen sollte ausreichende Sicherheit bieten... Platte fehlend lassen ist besser als RAID5. Es muss dann am Ende nur noch die fehlende Platte beschrieben werden, statt nochmal auf allen Platten die Struktur ändern zu müssen was bei einem RAID5->RAID6 Wechsel nötig wäre. Rein von der Redundanz/Sicherheit her ist es genauso gut wie RAID5, mathematisch etwas aufwendiger aber das ist ja vernachlässigbar *hust* Dein Plan klingt gut. Mach es so. Ich hab mal versucht das lokal durchzuspielen, war aber direkt ein Schuss in den Ofen. resize2fs hat sich bei mir (auch nach umount, fsck) geweigert das Dateisystem zu verkleinern. Ich habe es allerdings in einer anderen Dimension versucht, mit 1GB-Laufwerken statt 4T, deine Situation mit 16T+ kann ich hier nicht mal eben so nachstellen. Laut df war 1.1GiB frei, resize2fs hat sich trotzdem geweigert auf <4G zu verkleinern, ich hoffe das ist nur ein Limit für zu kleine Dateisysteme und nicht irgendwas anderes. Bevor /dev/loopX aus /dev/mdX entfernt wird: # echo $(( ($(blockdev --getsize64 /dev/mdX) - $(blockdev --getsize64 /dev/loopX)) / 1024 / 1024 ))M
3804M
# resize2fs /dev/md42 3804M
Requested size exceeds minimum size. ^ bevor du das RAID shrinkst, probier mal ob es bis zum resize2fs funktioniert bei dir. (du wirst das - $(loopX) * 2 nehmen müssen wenn du im 1. Schritt gleich 2 Platten entfernen willst)
|
Arny80Hexa
(Themenstarter)
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
frostschutz schrieb: mdadm hat da vor relativ kurzer Zeit ein größeres Data-Offset eingeführt (früher 1MB, heute 128MB), um dieses bei einem Grow etappenweise reduzieren zu können. Dadurch fällt die Notwendigkeit für ein Backup-File weg, das sonst (zumindest ganz am Anfang) nötig ist um den Grow-Vorgang absturzsicher zu machen. Du könntest auf dieses Feature verzichten indem du beim mdadm --create direkt --data-offset=1M angibst und dann die Grows eben explizit mit --backup-file=/mnt/irgendwo/datei anstößt.
Ich hab - wie im Wiki beschrieben - sowieso schon immer mit dem backup-file beim grow gearbeitet. Das mit dem Data-Offset ist ein guter Tip. Liegt hier das Problem was die Leute in den Mailing-Listen haben?
Mir sind hier noch keine Gurus über den Weg gelaufen. Das sind alles ganz normale, verrückte und bekloppte Menschen wie du und ich.
Gut, jetzt fühle ich mich heimischer! 😬 Mach gleich als RAID6, das ist einfacher.
Jupp, wie oben geschrieben fange ich gleich mit 4x4TB RAID6 an. P.s. Nochmals riesen Dank für deine umfangreiche Hilfe!
Das war mehr so gedacht für RAID6 auf 2 Platten (mit 2 Platten fehlend), aber deine Idee ist auch gut. Das ganze auf beiden Seiten zwar mit RAID6, aber einfacher Parity (also eine Platte fehlend) durchzuführen sollte ausreichende Sicherheit bieten... Platte fehlend lassen ist besser als RAID5. Es muss dann am Ende nur noch die fehlende Platte beschrieben werden, statt nochmal auf allen Platten die Struktur ändern zu müssen was bei einem RAID5->RAID6 Wechsel nötig wäre. Rein von der Redundanz/Sicherheit her ist es genauso gut wie RAID5, mathematisch etwas aufwendiger aber das ist ja vernachlässigbar *hust*
Aaahhh! Danke für den Hinweis. So hab ich das nämlich noch nicht gesehen.
Ich hab mal versucht das lokal durchzuspielen, war aber direkt ein Schuss in den Ofen. resize2fs hat sich bei mir (auch nach umount, fsck) geweigert das Dateisystem zu verkleinern. Ich habe es allerdings in einer anderen Dimension versucht, mit 1GB-Laufwerken statt 4T, deine Situation mit 16T+ kann ich hier nicht mal eben so nachstellen. Laut df war 1.1GiB frei, resize2fs hat sich trotzdem geweigert auf <4G zu verkleinern, ich hoffe das ist nur ein Limit für zu kleine Dateisysteme und nicht irgendwas anderes. Bevor /dev/loopX aus /dev/mdX entfernt wird: # echo $(( ($(blockdev --getsize64 /dev/mdX) - $(blockdev --getsize64 /dev/loopX)) / 1024 / 1024 ))M
3804M
# resize2fs /dev/md42 3804M
Requested size exceeds minimum size. ^ bevor du das RAID shrinkst, probier mal ob es bis zum resize2fs funktioniert bei dir. (du wirst das - $(loopX) * 2 nehmen müssen wenn du im 1. Schritt gleich 2 Platten entfernen willst)
Wollte es gerade ausprobieren. Haut nicht hin, aber ist glaube ich mein Fehler.
| homeserver boss # echo $(( ($(blockdev --getsize64 /dev/md0) - $(blockdev --getsize64 /dev/loopX)) / 1024 / 1024 ))M
blockdev: /dev/loopX kann nicht geöffnet werden: Datei oder Verzeichnis nicht gefunden
bash: (20003236085760 - ) / 1024 / 1024 : Syntax Fehler: Operator erwartet. (Fehlerverursachendes Zeichen ist ») / 1024 / 1024 «).
|
Ich hab /dev/loopX auch gar nicht. Weiß jetzt auch gerade nichts damit anzufangen (Laut Recherchen ist das ne Containerdatei?). Kenne das eigentlich nur irgendwie vom DVD-Laufwerk.
Ansonsten geht es bei dem Befehl darum zu ermitteln, wie viel Platz auf dem Laufwerk ist, und um wie viel ich das schrumpfen kann, richtig?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Ich hatte zum Testen ein RAID aus Loop-Devices aufgebaut, /dev/loopX ist also ein Laufwerk von /dev/mdX gewesen.
|
Arny80Hexa
(Themenstarter)
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
Ok, also denke ich du wolltest das hier haben?: | echo $(( ($(blockdev --getsize64 /dev/md0) - $(blockdev --getsize64 /dev/sdh1)) / 1024 / 1024 ))M
15261129M
|
sdh1 war das letzte Laufwerk, was ich vor ein paar Tagen hinzugefügt hatte.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Ja, so ungefähr, und das ist dann die Größe auf die du mindestens verkleinern musst um das RAID um 1 Laufwerk (sdh1) schrumpfen zu lassen ohne daß nachher das Dateisystemende fehlt, was ext4 gar nicht gerne sieht. Aber 15261129M sind ja ca. 16T und du wolltest ja im ersten Schritt gleich auf 12T gehen so wie ich dich verstanden habe, also die Membergröße zweimal abziehen statt nur einmal...
|
Arny80Hexa
(Themenstarter)
Anmeldungsdatum: 29. Juli 2011
Beiträge: 96
|
Ist schon ein bissel her, weil mir gerade ein bisschen die Zeit fehlt, aber ich habe es in der Zwischenzeit geschafft auf dem Raid so viel frei zu räumen, dass einem ersten Shrink-Vorgang nichts im Wege stehen sollte.
frostschutz Ich habe deinen Befehl so abgewandelt, dass er jetzt eigentlich die Größe mit abgezogen 2x4TB Platten anzeigen sollte: | homeserver boss # echo $(( ($(blockdev --getsize64 /dev/md0)) / 1024 / 1024 ))M
19076572M
homeserver boss # echo $(( ($(blockdev --getsize64 /dev/md0) - $(blockdev --getsize64 /dev/sdh1)) / 1024 / 1024 ))M
15261129M
homeserver boss # echo $(( ($(blockdev --getsize64 /dev/md0) - $(blockdev --getsize64 /dev/sdh1) - $(blockdev --getsize64 /dev/sdg1)) / 1024 / 1024 ))M
11445686M
|
| homeserver boss # df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/md0 15T 9,5T 4,3T 70% /media/data
homeserver boss # df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/md0 15504259492 10197199824 4525666880 70% /media/data
|
Ist das so korrekt?
Wenn ja, wie gehts jetzt weiter? Also wie leite ich den Shrink-Vorgang ein (gerne das Dateisystem ein wenig mehr schrumpfen um keine Probleme zu bekommen, wenn ich dann zwei Platten raus ziehe. Platz sollte ja genug frei sein inzwischen)?
|