info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
mdadm bei neuen Plattennamen
0 views
Skip to first unread message
Marco Moock
Nov 15, 2023, 1:13:10 AM11/15/23
to
Hallo zusammen!
Kann mdadm verkraften, wenn sich die Namen der Platten ändern (z.B.
weil eine Platte entfernt und aus sdd halt sdc wird)?
Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist das
für mdadm anhand diesem identifizierbar?
Falls nicht: Was muss man an Vorbereitung machen?
--
Gruß
Marco
Kann mdadm verkraften, wenn sich die Namen der Platten ändern (z.B.
weil eine Platte entfernt und aus sdd halt sdc wird)?
Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist das
für mdadm anhand diesem identifizierbar?
Falls nicht: Was muss man an Vorbereitung machen?
--
Gruß
Marco
Markus Schaaf
Nov 15, 2023, 2:57:25 AM11/15/23
to
Am 15.11.23 um 07:13 schrieb Marco Moock:
> Kann mdadm verkraften, wenn sich die Namen der Platten ändern (z.B.
> weil eine Platte entfernt und aus sdd halt sdc wird)?
Ja.
> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist das
> für mdadm anhand diesem identifizierbar?
Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
machen könnte, wäre die Liste der Devices, auf denen MD nach
Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
DEVICE partitions
was für Deinen Fall okay wäre.
MfG
> Kann mdadm verkraften, wenn sich die Namen der Platten ändern (z.B.
> weil eine Platte entfernt und aus sdd halt sdc wird)?
> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist das
> für mdadm anhand diesem identifizierbar?
machen könnte, wäre die Liste der Devices, auf denen MD nach
Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
DEVICE partitions
was für Deinen Fall okay wäre.
MfG
Marco Moock
Nov 15, 2023, 3:23:08 AM11/15/23
to
Am 15.11.2023 um 08:57:22 Uhr schrieb Markus Schaaf:
> Am 15.11.23 um 07:13 schrieb Marco Moock:
> Am 15.11.23 um 07:13 schrieb Marco Moock:
> > Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist
> > das für mdadm anhand diesem identifizierbar?
>
> Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
> machen könnte, wäre die Liste der Devices, auf denen MD nach
> Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
>
> DEVICE partitions
Bei mir ist diese Zeile auskommentiert:
> > das für mdadm anhand diesem identifizierbar?
>
> Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
> machen könnte, wäre die Liste der Devices, auf denen MD nach
> Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
>
> DEVICE partitions
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to
scan, using # wildcards if desired.
#DEVICE partitions containers
Ist mit "by default" gemeint, dass das passiert, ohne dass das in der
Datei steht?
Was ist dann mit der initramfs?
Prüft das nur UUID oder auch die Gerätenamen?
Das RAID ist sowohl / als auch /boot.
Kay Martinen
Nov 15, 2023, 4:00:02 AM11/15/23
to
Am 15.11.23 um 09:23 schrieb Marco Moock:
nachlesen. Aber built-in heißt üblicherweise ein Default der greift wenn
in der Konfig NICHTS dazu steht.
> Was ist dann mit der initramfs?
> Prüft das nur UUID oder auch die Gerätenamen?
>
> Das RAID ist sowohl / als auch /boot.
Es gibt einen Partitionstyp "Raid-autodetect" und diese hat dann eine
UUID. Der Gerätename ist ja oft positionsabhängig (im scan-durchlauf)
kann aber m.E. auch über eine udev-regel festgelegt werden.
mdadm sollte also nach obigem partitionstyp suchen und da evtl.
vorhandene Daten zum raid lesen. Das sollte dann automagisch gehen außer
du hängst eine leere Platte als ersatz für eine Defekte rein.
Aber so wie ich's sehe mußt du der auch nur den Partitionstyp geben und
danach ein Sync anstoßen - falls mdadm das nicht schon selbst los tritt.
Danach sollten / und /boot auch auf der neuen Platte sein.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
> Am 15.11.2023 um 08:57:22 Uhr schrieb Markus Schaaf:
>
>> Am 15.11.23 um 07:13 schrieb Marco Moock:
>>> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist
>>> das für mdadm anhand diesem identifizierbar?
>>
>> Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
>> machen könnte, wäre die Liste der Devices, auf denen MD nach
>> Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
>>
>> DEVICE partitions
>
> Bei mir ist diese Zeile auskommentiert:
>
> # by default (built-in), scan all partitions (/proc/partitions) and all
> # containers for MD superblocks. alternatively, specify devices to
> scan, using # wildcards if desired.
> #DEVICE partitions containers
>
> Ist mit "by default" gemeint, dass das passiert, ohne dass das in der
> Datei steht?
Lese ich so, ja. Welche container damit gemeint sind müsste ich
>
>> Am 15.11.23 um 07:13 schrieb Marco Moock:
>>> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist
>>> das für mdadm anhand diesem identifizierbar?
>>
>> Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
>> machen könnte, wäre die Liste der Devices, auf denen MD nach
>> Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
>>
>> DEVICE partitions
>
> Bei mir ist diese Zeile auskommentiert:
>
> # by default (built-in), scan all partitions (/proc/partitions) and all
> # containers for MD superblocks. alternatively, specify devices to
> scan, using # wildcards if desired.
> #DEVICE partitions containers
>
> Ist mit "by default" gemeint, dass das passiert, ohne dass das in der
> Datei steht?
nachlesen. Aber built-in heißt üblicherweise ein Default der greift wenn
in der Konfig NICHTS dazu steht.
> Was ist dann mit der initramfs?
> Prüft das nur UUID oder auch die Gerätenamen?
>
> Das RAID ist sowohl / als auch /boot.
UUID. Der Gerätename ist ja oft positionsabhängig (im scan-durchlauf)
kann aber m.E. auch über eine udev-regel festgelegt werden.
mdadm sollte also nach obigem partitionstyp suchen und da evtl.
vorhandene Daten zum raid lesen. Das sollte dann automagisch gehen außer
du hängst eine leere Platte als ersatz für eine Defekte rein.
Aber so wie ich's sehe mußt du der auch nur den Partitionstyp geben und
danach ein Sync anstoßen - falls mdadm das nicht schon selbst los tritt.
Danach sollten / und /boot auch auf der neuen Platte sein.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Marco Moock
Nov 15, 2023, 4:29:31 AM11/15/23
to
Am 15.11.2023 um 09:55:07 Uhr schrieb Kay Martinen:
> Aber so wie ich's sehe mußt du der auch nur den Partitionstyp geben
> und danach ein Sync anstoßen - falls mdadm das nicht schon selbst los
> tritt.
>
> Danach sollten / und /boot auch auf der neuen Platte sein.
sync ist längst erledigt, es geht mir nur darum, dass das nach dem Boot
> Aber so wie ich's sehe mußt du der auch nur den Partitionstyp geben
> und danach ein Sync anstoßen - falls mdadm das nicht schon selbst los
> tritt.
>
> Danach sollten / und /boot auch auf der neuen Platte sein.
auch noch so erkannt wird.
Markus Schaaf
Nov 15, 2023, 6:28:06 AM11/15/23
to
Am 15.11.23 um 09:23 schrieb Marco Moock:
> Am 15.11.2023 um 08:57:22 Uhr schrieb Markus Schaaf:
>
>> Am 15.11.23 um 07:13 schrieb Marco Moock:
>>> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist
>>> das für mdadm anhand diesem identifizierbar?
>>
>> Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
>> machen könnte, wäre die Liste der Devices, auf denen MD nach
>> Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
>>
>> DEVICE partitions
>
> Bei mir ist diese Zeile auskommentiert:
>
> # by default (built-in), scan all partitions (/proc/partitions) and all
> # containers for MD superblocks. alternatively, specify devices to
> scan, using # wildcards if desired.
> #DEVICE partitions containers
>
> Ist mit "by default" gemeint, dass das passiert, ohne dass das in der
> Datei steht?
Wenn gar keine DEVICE-Zeile existiert, vielleicht. :-) Liest sich
>
>> Am 15.11.23 um 07:13 schrieb Marco Moock:
>>> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist
>>> das für mdadm anhand diesem identifizierbar?
>>
>> Natürlich, das ist ja der Sinn. Das Einzige, was u.U. Probleme
>> machen könnte, wäre die Liste der Devices, auf denen MD nach
>> Arrays sucht. Siehe /etc/mdadm.conf! Normal steht da
>>
>> DEVICE partitions
>
> Bei mir ist diese Zeile auskommentiert:
>
> # by default (built-in), scan all partitions (/proc/partitions) and all
> # containers for MD superblocks. alternatively, specify devices to
> scan, using # wildcards if desired.
> #DEVICE partitions containers
>
> Ist mit "by default" gemeint, dass das passiert, ohne dass das in der
> Datei steht?
zumindest so. Ich bin bei sowas immer für's explizite
Hinschreiben, dann gibt's keine Überraschungen, wenn irgendein
Tool mal eine DEVICE-Zeile "hinzufügt".
> Was ist dann mit der initramfs?
> Prüft das nur UUID oder auch die Gerätenamen?
also hängt es von Deiner initrd ab, wie es läuft. Bei mir
(Arch-Linux, mkinitcpio) wird die mdadm.conf beim Bauen der
initrd kopiert. Früher war es so, dass in der initrd nur explizit
in der mdadm.conf enthaltene Arrays gestartet wurden. Aber das
funktioniert bei Dir ja bereits. Arrays werden per UUID erkannt.
Es kann jedoch nicht schaden, das wichtige Array mit / und /boot
explizit hinzuschreiben. Falls Deine mdadm.conf bisher leer ist,
kannst Du sie mit
mdadm --detail --scan >> /etc/mdadm.conf
befüllen.
MfG
Marco Moock
Nov 15, 2023, 6:57:09 AM11/15/23
to
Am 15.11.2023 um 12:28:03 Uhr schrieb Markus Schaaf:
> Falls Deine mdadm.conf bisher leer ist, kannst Du sie mit
>
> mdadm --detail --scan >> /etc/mdadm.conf
Meine ist nicht leer und hat die Arrays drin.
> Falls Deine mdadm.conf bisher leer ist, kannst Du sie mit
>
> mdadm --detail --scan >> /etc/mdadm.conf
Kay Martinen
Nov 15, 2023, 8:20:02 AM11/15/23
to
Am 15.11.23 um 12:57 schrieb Marco Moock:
Und du wolltest jetzt wissen ob das Reboot-fest ist? Bei einem Raid-1
würde ich das schon meinen wenn; wie du ja nebenan schriebst; der sync
schon erledigt ist.
Da war allerdings mal was mit dem evtl. nicht kopierten Bootsector aber
mir fallen jetzt die Rahmenbedingungen dazu nicht mehr ein. Das wäre
sonst das einzige was mir einfällt und nur ein Problem wenn die Eine
Platte MIT Bootsektor nun ausfallen sollte.
Der sollte aber doch beim rebuild mit rüber kopiert worden sein oder?
Bei Obigem ging's um EISFAIR-Linux und AFAIR mußte man eh ein mal den
kernel neu installieren um dort eine neue initrd gebaut zu bekommen die
änderungen/neues im Array dann auch nach dem reboot berücksichtigt.
Allerdings ist EISFAIR da wohl stärker automagisiert als andere Distros.
würde ich das schon meinen wenn; wie du ja nebenan schriebst; der sync
schon erledigt ist.
Da war allerdings mal was mit dem evtl. nicht kopierten Bootsector aber
mir fallen jetzt die Rahmenbedingungen dazu nicht mehr ein. Das wäre
sonst das einzige was mir einfällt und nur ein Problem wenn die Eine
Platte MIT Bootsektor nun ausfallen sollte.
Der sollte aber doch beim rebuild mit rüber kopiert worden sein oder?
Bei Obigem ging's um EISFAIR-Linux und AFAIR mußte man eh ein mal den
kernel neu installieren um dort eine neue initrd gebaut zu bekommen die
änderungen/neues im Array dann auch nach dem reboot berücksichtigt.
Allerdings ist EISFAIR da wohl stärker automagisiert als andere Distros.
Marco Moock
Nov 15, 2023, 8:32:30 AM11/15/23
to
Am 15.11.2023 um 14:12:55 Uhr schrieb Kay Martinen:
> Am 15.11.23 um 12:57 schrieb Marco Moock:
> > Am 15.11.2023 um 12:28:03 Uhr schrieb Markus Schaaf:
> >
> >> Falls Deine mdadm.conf bisher leer ist, kannst Du sie mit
> >>
> >> mdadm --detail --scan >> /etc/mdadm.conf
> >
> > Meine ist nicht leer und hat die Arrays drin.
> >
>
> Und du wolltest jetzt wissen ob das Reboot-fest ist? Bei einem Raid-1
> würde ich das schon meinen wenn; wie du ja nebenan schriebst; der
> sync schon erledigt ist.
Der Test hat ergeben: mdadm verkraftet Änderungen des Gerätenamens
> Am 15.11.23 um 12:57 schrieb Marco Moock:
> > Am 15.11.2023 um 12:28:03 Uhr schrieb Markus Schaaf:
> >
> >> Falls Deine mdadm.conf bisher leer ist, kannst Du sie mit
> >>
> >> mdadm --detail --scan >> /etc/mdadm.conf
> >
> > Meine ist nicht leer und hat die Arrays drin.
> >
>
> Und du wolltest jetzt wissen ob das Reboot-fest ist? Bei einem Raid-1
> würde ich das schon meinen wenn; wie du ja nebenan schriebst; der
> sync schon erledigt ist.
problemlos.
Dafür gibt es nun anderen Stunk.
> Da war allerdings mal was mit dem evtl. nicht kopierten Bootsector
> aber mir fallen jetzt die Rahmenbedingungen dazu nicht mehr ein. Das
> wäre sonst das einzige was mir einfällt und nur ein Problem wenn die
> Eine Platte MIT Bootsektor nun ausfallen sollte.
>
> Der sollte aber doch beim rebuild mit rüber kopiert worden sein oder?
Partition liegt.
Ist hier aber erstmal nicht Thema, da das ein UEFI-System ist.
Diedrich Ehlerding
Nov 15, 2023, 11:37:48 AM11/15/23
to
Marco Moock meinte:
> Kann mdadm verkraften, wenn sich die Namen der Platten ändern (z.B.
> weil eine Platte entfernt und aus sdd halt sdc wird)?
Ja, mdadm verkaftet das, es erkennt, welche Platten zusammengehören, und
setzt das md-Device dann richtig zusammen..
Aber, für den Fall, dass du mal an Servern mit mehreren bis vielen
Platten zu tun hast, vielleicht sogar in unterschiedlichen Gehäusen, und
dass du vielleicht auch verschiedene SATA-Controller oder -Busse hast:
Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch halbwegs
unkritisch ist, wenn du zum Zeitpungt des mdadm create weißt, was du
tust, und die Platten sicher identifizierst). Verwende statt dessen zB
die Namen in /dev/disk/by-id/, um Platten zu indentifizieren, diese
Namen ändern sich nicht.
Definiere also die Platten, die du überhaupt für md in Erwägung ziehen
willst, indem du sowas wie
DEVICE /dev/disk/by-id/.*
(oder eben genau die, die du verwenden willst, falls du mehrere hast) in
mdadm.conf, Und verwende dann diese Namen beim mdadm create.
Wenn du das md-Device einmal erzeugt hast, bekommst du eine uuid. Damit
dann dieses md-Device hinterher immer denselben Namen bekommt (du
könntest ja mehrere haben), schreibst du sie in mdadm.conf erwähnst; zB
(aus man mdadm.conf):
ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
und analoge Zeilen für /dev/md1, /dev/md2 usw. usf.
> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist das
> für mdadm anhand diesem identifizierbar?
Ja, da steht genau diese UUID drin.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
> Kann mdadm verkraften, wenn sich die Namen der Platten ändern (z.B.
> weil eine Platte entfernt und aus sdd halt sdc wird)?
setzt das md-Device dann richtig zusammen..
Aber, für den Fall, dass du mal an Servern mit mehreren bis vielen
Platten zu tun hast, vielleicht sogar in unterschiedlichen Gehäusen, und
dass du vielleicht auch verschiedene SATA-Controller oder -Busse hast:
Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch halbwegs
unkritisch ist, wenn du zum Zeitpungt des mdadm create weißt, was du
tust, und die Platten sicher identifizierst). Verwende statt dessen zB
die Namen in /dev/disk/by-id/, um Platten zu indentifizieren, diese
Namen ändern sich nicht.
Definiere also die Platten, die du überhaupt für md in Erwägung ziehen
willst, indem du sowas wie
DEVICE /dev/disk/by-id/.*
(oder eben genau die, die du verwenden willst, falls du mehrere hast) in
mdadm.conf, Und verwende dann diese Namen beim mdadm create.
Wenn du das md-Device einmal erzeugt hast, bekommst du eine uuid. Damit
dann dieses md-Device hinterher immer denselben Namen bekommt (du
könntest ja mehrere haben), schreibst du sie in mdadm.conf erwähnst; zB
(aus man mdadm.conf):
ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
und analoge Zeilen für /dev/md1, /dev/md2 usw. usf.
> Eigentlich sollten die RAID-Geräte ja einen Superblock haben. Ist das
> für mdadm anhand diesem identifizierbar?
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Marco Moock
Nov 15, 2023, 11:51:10 AM11/15/23
to
Am 15.11.2023 um 17:14:29 Uhr schrieb Diedrich Ehlerding:
> ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
Sind das die einzelnen UUIDs der Partitionen oder sind da weitere
> ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
Infos drin?
Das RAID hatte mal 4 (vorher 2, dann eine zusätzliche Platte, die aber
gleich verreckte und dann die 4, die jetzt bleibt). Die erste Platte
wurde dann entfernt.
root@srv1:~# mdadm --detail --scan
ARRAY /dev/md/1 metadata=1.2 name=srv1:1 UUID=ddd56544:71840e35:66eba575:e7372e97
ARRAY /dev/md/0 metadata=1.2 name=srv1:0 UUID=7a22c162:d4706a7f:9978b913:81417ce8
root@srv1:~# cat /etc/mdadm/mdadm.conf |grep ARR
ARRAY /dev/md/0 metadata=1.2 UUID=7a22c162:d4706a7f:9978b913:81417ce8 name=srv1:0
ARRAY /dev/md/1 metadata=1.2 UUID=ddd56544:71840e35:66eba575:e7372e97 name=srv1:1
root@srv1:~#
Diedrich Ehlerding
Nov 15, 2023, 12:10:52 PM11/15/23
to
Marco Moock meinte:
>> ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
>
> Sind das die einzelnen UUIDs der Partitionen oder sind da weitere
> Infos drin?
Nein. Das ist die UUID des Raidverbunds. Die wird beim mdadm --create
erzeugt. Du kannst sie im laufenden System mit mdadm --scan anschauen
>> ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
>
> Sind das die einzelnen UUIDs der Partitionen oder sind da weitere
> Infos drin?
erzeugt. Du kannst sie im laufenden System mit mdadm --scan anschauen
Marco Moock
Nov 15, 2023, 2:48:50 PM11/15/23
to
Am 15.11.2023 um 18:09:24 Uhr schrieb Diedrich Ehlerding:
> Marco Moock meinte:
>
> >> ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
> >
> > Sind das die einzelnen UUIDs der Partitionen oder sind da weitere
> > Infos drin?
>
> Nein. Das ist die UUID des Raidverbunds. Die wird beim mdadm --create
> erzeugt.
Was für IDs sind das nun?
> Marco Moock meinte:
>
> >> ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
> >
> > Sind das die einzelnen UUIDs der Partitionen oder sind da weitere
> > Infos drin?
>
> Nein. Das ist die UUID des Raidverbunds. Die wird beim mdadm --create
> erzeugt.
Hat der RAID-Verbund diese eine UUID oder ist sind das die UUIDs der
einzelnen RAID-Laufwerke (nicht die UUID der ext4-Partition etc.)?
> Du kannst sie im laufenden System mit mdadm --scan anschauen
--misc wird gefressen, gibt aber dann nix aus.
Diedrich Ehlerding
Nov 16, 2023, 1:34:46 AM11/16/23
to
Marco Moock meinte:
> Was für IDs sind das nun?
> Hat der RAID-Verbund diese eine UUID oder ist sind das die UUIDs der
> einzelnen RAID-Laufwerke (nicht die UUID der ext4-Partition etc.)?
Der Raid-Verbund hat eine UUID (jedenfalls wenn man das Array mit
mdadm --create erzeugt hat und nicht mit mdadm --build; letzteres sollte
man allerdings besser nicht tun, wenn man nicht sehr gute Gründe hat und
sehr genau weiß, was man tut). Das ist die, die in die mdadm.conf
gehört. Die steht in den Metadaten irgendwo auf der Platte bzw. der
Partition (bzw. auf jeder der zum Verbund gehörenden Platten bzw.
Partitionen); an diese Metadaten bzw. an der auf allen beteiligten
Platten gleichen ID in diesen Metadaten erkennt mdadm beim
mdadm --assemble, welche Stücke wie zusammengehören.
Platten (also /dev/sd[a-z]+) haben keine UUIDs, die haben Seriennummern,
und die findest du in /dev/disk/by-id/. Partitionen haben auch keine
UUID. UUIDs sind etwas Softwaregeneriertes, d.h. zB Filesysteme haben
eine, md-Arrays haben eine, LVM-Volumes haben eine.
> Was für IDs sind das nun?
> Hat der RAID-Verbund diese eine UUID oder ist sind das die UUIDs der
> einzelnen RAID-Laufwerke (nicht die UUID der ext4-Partition etc.)?
mdadm --create erzeugt hat und nicht mit mdadm --build; letzteres sollte
man allerdings besser nicht tun, wenn man nicht sehr gute Gründe hat und
sehr genau weiß, was man tut). Das ist die, die in die mdadm.conf
gehört. Die steht in den Metadaten irgendwo auf der Platte bzw. der
Partition (bzw. auf jeder der zum Verbund gehörenden Platten bzw.
Partitionen); an diese Metadaten bzw. an der auf allen beteiligten
Platten gleichen ID in diesen Metadaten erkennt mdadm beim
mdadm --assemble, welche Stücke wie zusammengehören.
Platten (also /dev/sd[a-z]+) haben keine UUIDs, die haben Seriennummern,
und die findest du in /dev/disk/by-id/. Partitionen haben auch keine
UUID. UUIDs sind etwas Softwaregeneriertes, d.h. zB Filesysteme haben
eine, md-Arrays haben eine, LVM-Volumes haben eine.
Marco Moock
Nov 16, 2023, 3:39:12 AM11/16/23
to
Am 16.11.2023 schrieb Diedrich Ehlerding
<diedrich....@t-online.de>:
> Marco Moock meinte:
>
> > Was für IDs sind das nun?
> > Hat der RAID-Verbund diese eine UUID oder ist sind das die UUIDs der
> > einzelnen RAID-Laufwerke (nicht die UUID der ext4-Partition etc.)?
>
> Der Raid-Verbund hat eine UUID (jedenfalls wenn man das Array mit
> mdadm --create erzeugt hat und nicht mit mdadm --build; letzteres
> sollte man allerdings besser nicht tun, wenn man nicht sehr gute
> Gründe hat und sehr genau weiß, was man tut). Das ist die, die in die
> mdadm.conf gehört. Die steht in den Metadaten irgendwo auf der
> Platte bzw. der Partition (bzw. auf jeder der zum Verbund gehörenden
> Platten bzw. Partitionen); an diese Metadaten bzw. an der auf allen
> beteiligten Platten gleichen ID in diesen Metadaten erkennt mdadm
> beim mdadm --assemble, welche Stücke wie zusammengehören.
Bedeutet das, dass diese UUID aus dem einzelnen RAID-Gerät (nicht
md!) entfernt wird, wenn man dieses Gerät aus dem Array löscht?
> Platten (also /dev/sd[a-z]+) haben keine UUIDs, die haben
> Seriennummern, und die findest du in /dev/disk/by-id/. Partitionen
> haben auch keine UUID.
Was ist dann die Disk-GUID?
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_(LBA_1)
Was ist dann mit der PARTUUID bei GPT-Partitionen?
Die ist auch in der GPT und unabhängig von der UUID im Dateisystem.
<diedrich....@t-online.de>:
> Marco Moock meinte:
>
> > Was für IDs sind das nun?
> > Hat der RAID-Verbund diese eine UUID oder ist sind das die UUIDs der
> > einzelnen RAID-Laufwerke (nicht die UUID der ext4-Partition etc.)?
>
> Der Raid-Verbund hat eine UUID (jedenfalls wenn man das Array mit
> mdadm --create erzeugt hat und nicht mit mdadm --build; letzteres
> sollte man allerdings besser nicht tun, wenn man nicht sehr gute
> Gründe hat und sehr genau weiß, was man tut). Das ist die, die in die
> mdadm.conf gehört. Die steht in den Metadaten irgendwo auf der
> Platte bzw. der Partition (bzw. auf jeder der zum Verbund gehörenden
> Platten bzw. Partitionen); an diese Metadaten bzw. an der auf allen
> beteiligten Platten gleichen ID in diesen Metadaten erkennt mdadm
> beim mdadm --assemble, welche Stücke wie zusammengehören.
md!) entfernt wird, wenn man dieses Gerät aus dem Array löscht?
> Platten (also /dev/sd[a-z]+) haben keine UUIDs, die haben
> Seriennummern, und die findest du in /dev/disk/by-id/. Partitionen
> haben auch keine UUID.
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_table_header_(LBA_1)
Was ist dann mit der PARTUUID bei GPT-Partitionen?
Die ist auch in der GPT und unabhängig von der UUID im Dateisystem.
Marc Haber
Nov 16, 2023, 6:34:36 AM11/16/23
to
Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
>nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch halbwegs
>unkritisch ist, wenn du zum Zeitpungt des mdadm create weißt, was du
>tust, und die Platten sicher identifizierst). Verwende statt dessen zB
>die Namen in /dev/disk/by-id/, um Platten zu indentifizieren, diese
>Namen ändern sich nicht.
Das sollte man sich fett hinter die Ohren schreiben, und ich schließe
>Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
>nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch halbwegs
>unkritisch ist, wenn du zum Zeitpungt des mdadm create weißt, was du
>tust, und die Platten sicher identifizierst). Verwende statt dessen zB
>die Namen in /dev/disk/by-id/, um Platten zu indentifizieren, diese
>Namen ändern sich nicht.
mich da ausdrücklich nicht aus.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Dietz Proepper
Nov 16, 2023, 1:44:46 PM11/16/23
to
Marc Haber <mh+usene...@zugschl.us> wrote:
> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
> >nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch
> >halbwegs unkritisch ist, wenn du zum Zeitpungt des mdadm create
> >weißt, was du tust, und die Platten sicher identifizierst). Verwende
> >statt dessen zB die Namen in /dev/disk/by-id/, um Platten zu
> >indentifizieren, diese Namen ändern sich nicht.
>
> Das sollte man sich fett hinter die Ohren schreiben, und ich schließe
> mich da ausdrücklich nicht aus.
Wobei das bei Softwareraid eher unkritisch ist. Aber abgesehen davon
> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
> >nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch
> >halbwegs unkritisch ist, wenn du zum Zeitpungt des mdadm create
> >weißt, was du tust, und die Platten sicher identifizierst). Verwende
> >statt dessen zB die Namen in /dev/disk/by-id/, um Platten zu
> >indentifizieren, diese Namen ändern sich nicht.
>
> Das sollte man sich fett hinter die Ohren schreiben, und ich schließe
> mich da ausdrücklich nicht aus.
hast Du vollständig Recht, Gerätenamen sind ein wenig 2000ties.
--
+++ATH
Marco Moock
Nov 16, 2023, 2:29:54 PM11/16/23
to
Am 16.11.2023 um 19:44:44 Uhr schrieb Dietz Proepper:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>
> > Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> > >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
> > >nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch
> > >halbwegs unkritisch ist, wenn du zum Zeitpungt des mdadm create
> > >weißt, was du tust, und die Platten sicher identifizierst).
> > >Verwende statt dessen zB die Namen in /dev/disk/by-id/, um Platten
> > >zu indentifizieren, diese Namen ändern sich nicht.
> >
> > Das sollte man sich fett hinter die Ohren schreiben, und ich
> > schließe mich da ausdrücklich nicht aus.
>
> Wobei das bei Softwareraid eher unkritisch ist.
Was macht das denn bei Hardware-RAID kritischer?
> Marc Haber <mh+usene...@zugschl.us> wrote:
>
> > Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> > >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden. Auch
> > >nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch
> > >halbwegs unkritisch ist, wenn du zum Zeitpungt des mdadm create
> > >weißt, was du tust, und die Platten sicher identifizierst).
> > >Verwende statt dessen zB die Namen in /dev/disk/by-id/, um Platten
> > >zu indentifizieren, diese Namen ändern sich nicht.
> >
> > Das sollte man sich fett hinter die Ohren schreiben, und ich
> > schließe mich da ausdrücklich nicht aus.
>
> Wobei das bei Softwareraid eher unkritisch ist.
Die Controller haben doch sicher auch eine eindeutige Kennung für die
RAID-Geräte, um die zuordnen zu können.
Sonst gäbe es doch schon massives Chaos, wenn ne Platte nach nem
Neustart ne andere Nummer hat, weil umgesteckt.
Dietz Proepper
Nov 16, 2023, 3:21:20 PM11/16/23
to
Marco Moock <mm+s...@dorfdsl.de> wrote:
> Am 16.11.2023 um 19:44:44 Uhr schrieb Dietz Proepper:
>
> > Marc Haber <mh+usene...@zugschl.us> wrote:
> >
> > > Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> > > >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden.
> > > >Auch nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch
> > > >halbwegs unkritisch ist, wenn du zum Zeitpungt des mdadm create
> > > >weißt, was du tust, und die Platten sicher identifizierst).
> > > >Verwende statt dessen zB die Namen in /dev/disk/by-id/, um
> > > >Platten zu indentifizieren, diese Namen ändern sich nicht.
> > >
> > > Das sollte man sich fett hinter die Ohren schreiben, und ich
> > > schließe mich da ausdrücklich nicht aus.
> >
> > Wobei das bei Softwareraid eher unkritisch ist.
>
> Was macht das denn bei Hardware-RAID kritischer?
Bei HW-Raid weißt nie was passiert. Abgesehen davon - wenn es nicht
> Am 16.11.2023 um 19:44:44 Uhr schrieb Dietz Proepper:
>
> > Marc Haber <mh+usene...@zugschl.us> wrote:
> >
> > > Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> > > >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden.
> > > >Auch nicht, um ein Softwareraid zusammenzubauen (obwohl das nioch
> > > >halbwegs unkritisch ist, wenn du zum Zeitpungt des mdadm create
> > > >weißt, was du tust, und die Platten sicher identifizierst).
> > > >Verwende statt dessen zB die Namen in /dev/disk/by-id/, um
> > > >Platten zu indentifizieren, diese Namen ändern sich nicht.
> > >
> > > Das sollte man sich fett hinter die Ohren schreiben, und ich
> > > schließe mich da ausdrücklich nicht aus.
> >
> > Wobei das bei Softwareraid eher unkritisch ist.
>
> Was macht das denn bei Hardware-RAID kritischer?
wirklich el cheapo & el crappo ist eher gar nix.
--
+++ATH
Marcus Jodorf
Nov 17, 2023, 12:05:07 AM11/17/23
to
Marco Moock <mm+s...@dorfdsl.de> schrieb:
>> Falls Deine mdadm.conf bisher leer ist, kannst Du sie mit
>>
>> mdadm --detail --scan >> /etc/mdadm.conf
>
> Meine ist nicht leer und hat die Arrays drin.
Normal brauchst Du die Einträge da nicht. Aber es ist ein Fallback.
Ohne erkennt md auch einfach anhand des Partitionstyps und der GUID, was
zu einem Raid wie gehört.
Ich habe jahrelang md Raid6 benutzt, ohne mdadm.conf und alle Platten
waren in hotplug Slots und es war schlicht egal, welche Platte man wo
reingeschoben hat und was sdc, sdb, sdj, whatever war.
mdadm.conf ist eher wie Gürtel zum Hosenträger.
Und heutzutage verwendet man natürlich stattdessen ZFS. Weil Platten
sind mittlerweile viel zu groß, als daß man auf ein Filesystem vertrauen
könnte, das keine Checksummen für alles verwendet.
(Ich habe mittlerweile 8 x Exos 18TB als zraid2 (entspricht ungefähr
raid6) am Laufen. Weiterer großer Vorteil: Während md-raid einen Scrub
Durchlauf macht, ist im Regelfall alles zäh. Ganz lange sehr zäh. Und
bei 18 TB Platten dauert das ungefähr 24h bei ziemlich maximalem speed.
Bei ZFS merkt man von eine Scrub (resilver bei ZFS genannt) so ziemlich
genau gar nichts.)
Man kann md-raid da konfigurieren, aber es ist völlig
unintelligent. Begrenzt man das Tempo für rebuild/scrub dauert es ewig,
setzt man großzügige Grenzen, dann ist rebuild/scrub schnell aber die
User verhungern. Das ist da nicht annähernd auf dem Level von ZFS.
Gruß,
Marcus
⚂⚃
>> Falls Deine mdadm.conf bisher leer ist, kannst Du sie mit
>>
>> mdadm --detail --scan >> /etc/mdadm.conf
>
> Meine ist nicht leer und hat die Arrays drin.
Ohne erkennt md auch einfach anhand des Partitionstyps und der GUID, was
zu einem Raid wie gehört.
Ich habe jahrelang md Raid6 benutzt, ohne mdadm.conf und alle Platten
waren in hotplug Slots und es war schlicht egal, welche Platte man wo
reingeschoben hat und was sdc, sdb, sdj, whatever war.
mdadm.conf ist eher wie Gürtel zum Hosenträger.
Und heutzutage verwendet man natürlich stattdessen ZFS. Weil Platten
sind mittlerweile viel zu groß, als daß man auf ein Filesystem vertrauen
könnte, das keine Checksummen für alles verwendet.
(Ich habe mittlerweile 8 x Exos 18TB als zraid2 (entspricht ungefähr
raid6) am Laufen. Weiterer großer Vorteil: Während md-raid einen Scrub
Durchlauf macht, ist im Regelfall alles zäh. Ganz lange sehr zäh. Und
bei 18 TB Platten dauert das ungefähr 24h bei ziemlich maximalem speed.
Bei ZFS merkt man von eine Scrub (resilver bei ZFS genannt) so ziemlich
genau gar nichts.)
Man kann md-raid da konfigurieren, aber es ist völlig
unintelligent. Begrenzt man das Tempo für rebuild/scrub dauert es ewig,
setzt man großzügige Grenzen, dann ist rebuild/scrub schnell aber die
User verhungern. Das ist da nicht annähernd auf dem Level von ZFS.
Gruß,
Marcus
⚂⚃
Diedrich Ehlerding
Nov 17, 2023, 3:52:42 AM11/17/23
to
Dietz Proepper meinte:
>> >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden.
[...]
Inhalt identifiziert - sei es über mdadm, sei es über LVM, oder sei es
das Label des Filesystems, oder wie auch immer. Kritisch ist es immer
dann, wenn man die entsprechenden Label auf die Platte schreibt - also
beim Partitionieren, beim mkfs, beim Erzeugen des Raid usw. (welche
Platte spricht man da eigentlich an?); im Fall md auch dann, wenn mal
eine Platte ausfällt, man eine neue reinsteckt (um den md-Spiegel zu
reparieren), und dann erwartet, dass die denselben sd-Namen bekommt, den
vorher die ausgefallene Platte hatte. Oder wenn man mal von USB ein
Rettungssystem bootet und dann glaubt, dass die Platten dieselben
Legacy-Namen bekommen, die sie im Produktivsystem hatten.
> Aber abgesehen davon
> hast Du vollständig Recht, Gerätenamen sind ein wenig 2000ties.
Das habe ich schon Mitte der 2000er Jahre auf einer offiziellen Folie
von Redhat gelesen; da ging es um den kernel 2.6. Mit anderen Worten,
das ist schon seit >15 Jahren best practice.
Na ja, es hat ja auch >20 Jahre gedauert, bis sich im Usenet Umlaute,
Mime, UTF-8 usw. durchgesetzt haben; wieso sollte das bei Linux-Features
anders sein ... ITler sind halt mega-konservativ.
>> >Du solltest _nie_ diese Legacy-Namen /dev/sd[a-z]+ verwenden.
>> Das sollte man sich fett hinter die Ohren schreiben, und ich schließe
>> mich da ausdrücklich nicht aus.
>
> Wobei das bei Softwareraid eher unkritisch ist.
Es ist immer dann unkritisch, wenn man die Platten auf irgendeine Art am
>> mich da ausdrücklich nicht aus.
>
> Wobei das bei Softwareraid eher unkritisch ist.
Inhalt identifiziert - sei es über mdadm, sei es über LVM, oder sei es
das Label des Filesystems, oder wie auch immer. Kritisch ist es immer
dann, wenn man die entsprechenden Label auf die Platte schreibt - also
beim Partitionieren, beim mkfs, beim Erzeugen des Raid usw. (welche
Platte spricht man da eigentlich an?); im Fall md auch dann, wenn mal
eine Platte ausfällt, man eine neue reinsteckt (um den md-Spiegel zu
reparieren), und dann erwartet, dass die denselben sd-Namen bekommt, den
vorher die ausgefallene Platte hatte. Oder wenn man mal von USB ein
Rettungssystem bootet und dann glaubt, dass die Platten dieselben
Legacy-Namen bekommen, die sie im Produktivsystem hatten.
> Aber abgesehen davon
> hast Du vollständig Recht, Gerätenamen sind ein wenig 2000ties.
von Redhat gelesen; da ging es um den kernel 2.6. Mit anderen Worten,
das ist schon seit >15 Jahren best practice.
Na ja, es hat ja auch >20 Jahre gedauert, bis sich im Usenet Umlaute,
Mime, UTF-8 usw. durchgesetzt haben; wieso sollte das bei Linux-Features
anders sein ... ITler sind halt mega-konservativ.
0 new messages