Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
E1: Partition im Raid-Verbund verkleinern
18 views
Skip to first unread message
Rolf Bensch
May 13, 2016, 2:40:49 AM5/13/16
to
Hallo NG,
aus nicht mehr nachvollziehbaren Gründen ist mein Raid-Verbund mit /data
bis zum letzten Bit der Laufwerke einer Partition md0 zugewiesen. Das
erzeugt Probleme mit dem Superblock und mdadm.conf. Die Partition soll
daher etwas verkleinert werden. Vor dem Einsatz von gparted wurde ich
gewarnt.
Wie mache ich das am besten?
base : 2.7.2
eiskernel: 2.20.1 (3.2.77-eisfair-1-SMP)
ibs-server # fdisk -l
...
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x8c3d3ef5
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x1dde783f
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
...
Disk /dev/md0: 931.5 GiB, 1000203747328 bytes, 1953522944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Grüße Rolf
-> http://forum.nettworks.org/index.php?t=msg&th=7229&goto=47650&#msg_47650
aus nicht mehr nachvollziehbaren Gründen ist mein Raid-Verbund mit /data
bis zum letzten Bit der Laufwerke einer Partition md0 zugewiesen. Das
erzeugt Probleme mit dem Superblock und mdadm.conf. Die Partition soll
daher etwas verkleinert werden. Vor dem Einsatz von gparted wurde ich
gewarnt.
Wie mache ich das am besten?
base : 2.7.2
eiskernel: 2.20.1 (3.2.77-eisfair-1-SMP)
ibs-server # fdisk -l
...
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x8c3d3ef5
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x1dde783f
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
...
Disk /dev/md0: 931.5 GiB, 1000203747328 bytes, 1953522944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Grüße Rolf
-> http://forum.nettworks.org/index.php?t=msg&th=7229&goto=47650&#msg_47650
Thomas Zweifel
May 13, 2016, 9:50:02 AM5/13/16
to
Hallo Rolf
Am 13.05.2016 um 08:40 schrieb Rolf Bensch:
> Hallo NG,
>
> aus nicht mehr nachvollziehbaren Gründen ist mein Raid-Verbund mit /data
> bis zum letzten Bit der Laufwerke einer Partition md0 zugewiesen. Das
> erzeugt Probleme mit dem Superblock und mdadm.conf.
Wie Marcus Roeckrath es schon treffend festgehalten hat, ist es nicht
die Schuld der User, die sich an den Eisfair-Leitfaden zum erstellen
eines RAIDs gehalten haben, sondern mit dem geänderten Verhalten von
fdisk und mdadm dazu gekommen.
Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
Das Problem könnte wieder auftreten, wenn Du die Platten mit einer
anderen Linux Distribution verwenden möchtest, ansonsten ist aus meiner
Sicht kein zwingender Handlungsbedarf gegeben.
> Die Partition soll daher etwas verkleinert werden.
>
Sachen interessieren:
Der Füllstand des Laufwerks, um den zeitlichen Rahmen abzuschätzen
df md0
und die Blockgrösse des Dateisystems
tune2fs -l /dev/md0 | grep 'Block size'
Bei Gelegenheit einen Blick auf die SMART Werte der Platten werfen, wäre
auch nicht verkehrt.
Gruss Thomas
Am 13.05.2016 um 08:40 schrieb Rolf Bensch:
> Hallo NG,
>
> aus nicht mehr nachvollziehbaren Gründen ist mein Raid-Verbund mit /data
> bis zum letzten Bit der Laufwerke einer Partition md0 zugewiesen. Das
> erzeugt Probleme mit dem Superblock und mdadm.conf.
die Schuld der User, die sich an den Eisfair-Leitfaden zum erstellen
eines RAIDs gehalten haben, sondern mit dem geänderten Verhalten von
fdisk und mdadm dazu gekommen.
Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
Das Problem könnte wieder auftreten, wenn Du die Platten mit einer
anderen Linux Distribution verwenden möchtest, ansonsten ist aus meiner
Sicht kein zwingender Handlungsbedarf gegeben.
> Die Partition soll daher etwas verkleinert werden.
>
> Wie mache ich das am besten?
>
> base : 2.7.2
> eiskernel: 2.20.1 (3.2.77-eisfair-1-SMP)
>
> ibs-server # fdisk -l
> ...
> Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>
> base : 2.7.2
> eiskernel: 2.20.1 (3.2.77-eisfair-1-SMP)
>
> ibs-server # fdisk -l
> ...
> Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Device Boot Start End Sectors Size Id Type
> /dev/sdc1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
>
> Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> /dev/sdc1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
>
> Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> /dev/sdd1 2048 1953525167 1953523120 931.5G fd Linux raid autodetect
Wenn Du die Anpassung dennoch machen willst, würden mich noch folgende
Sachen interessieren:
Der Füllstand des Laufwerks, um den zeitlichen Rahmen abzuschätzen
df md0
und die Blockgrösse des Dateisystems
tune2fs -l /dev/md0 | grep 'Block size'
Bei Gelegenheit einen Blick auf die SMART Werte der Platten werfen, wäre
auch nicht verkehrt.
Gruss Thomas
Marcus Roeckrath
May 13, 2016, 10:00:03 AM5/13/16
to
Hallo Thomas,
Thomas Zweifel wrote:
> Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
Behoben ist es in 2.21.0. :-)
--
Gruss Marcus
Thomas Zweifel wrote:
> Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
--
Gruss Marcus
Thomas Zweifel
May 13, 2016, 10:10:02 AM5/13/16
to
Am 13.05.2016 um 15:45 schrieb Thomas Zweifel:
> Der Füllstand des Laufwerks, um den zeitlichen Rahmen abzuschätzen
>
> df md0
df /dev/md0
> Der Füllstand des Laufwerks, um den zeitlichen Rahmen abzuschätzen
>
> df md0
Mit ganzem Pfad, natürlich! ;-)
Gruss Thomas
Thomas Zweifel
May 13, 2016, 10:30:02 AM5/13/16
to
Hallo Marcus
Am 13.05.2016 um 15:59 schrieb Marcus Roeckrath:
> Thomas Zweifel wrote:
>
>> Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
>
> Behoben ist es in 2.21.0. :-)
Womit Du richtig liegst!
Gruss Thomas
Am 13.05.2016 um 15:59 schrieb Marcus Roeckrath:
> Thomas Zweifel wrote:
>
>> Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
>
> Behoben ist es in 2.21.0. :-)
Gruss Thomas
Rolf Bensch
May 13, 2016, 10:31:59 AM5/13/16
to
Hallo Thomas,
Am 13.05.2016 um 15:45 schrieb Thomas Zweifel:
> Das Problem könnte wieder auftreten, wenn Du die Platten mit einer
> anderen Linux Distribution verwenden möchtest, ansonsten ist aus meiner
> Sicht kein zwingender Handlungsbedarf gegeben.
>
>
>
>> Die Partition soll daher etwas verkleinert werden.
>>
>> Wie mache ich das am besten?
>>...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 961433544 142717184 769878288 16% /data
# tune2fs -l /dev/md0 | grep "Block size"
Block size: 4096
> Bei Gelegenheit einen Blick auf die SMART Werte der Platten werfen, wäre
> auch nicht verkehrt.
Das habe ich immer im Blick. Das Backup funktioniert auch zuverlässig :-))
Bevor ich entscheide ob ich das durchführe, möchte ich den Aufwand und
das Risiko abschätzen können. Bis dahin belasse ich den aktuellen Kernel
auf dem Server.
Grüße Rolf
Am 13.05.2016 um 15:45 schrieb Thomas Zweifel:
> Hallo Rolf
>
> Am 13.05.2016 um 08:40 schrieb Rolf Bensch:
>> Hallo NG,
>>
>> aus nicht mehr nachvollziehbaren Gründen ist mein Raid-Verbund mit /data
>> bis zum letzten Bit der Laufwerke einer Partition md0 zugewiesen. Das
>> erzeugt Probleme mit dem Superblock und mdadm.conf.
>
> Wie Marcus Roeckrath es schon treffend festgehalten hat, ist es nicht
> die Schuld der User, die sich an den Eisfair-Leitfaden zum erstellen
> eines RAIDs gehalten haben, sondern mit dem geänderten Verhalten von
> fdisk und mdadm dazu gekommen.
>
> Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
Tom ist sehr fix :-))
>
> Am 13.05.2016 um 08:40 schrieb Rolf Bensch:
>> Hallo NG,
>>
>> aus nicht mehr nachvollziehbaren Gründen ist mein Raid-Verbund mit /data
>> bis zum letzten Bit der Laufwerke einer Partition md0 zugewiesen. Das
>> erzeugt Probleme mit dem Superblock und mdadm.conf.
>
> Wie Marcus Roeckrath es schon treffend festgehalten hat, ist es nicht
> die Schuld der User, die sich an den Eisfair-Leitfaden zum erstellen
> eines RAIDs gehalten haben, sondern mit dem geänderten Verhalten von
> fdisk und mdadm dazu gekommen.
>
> Das Problem wurde mit dem Test-Kernel (2.20.1) behoben.
> Das Problem könnte wieder auftreten, wenn Du die Platten mit einer
> anderen Linux Distribution verwenden möchtest, ansonsten ist aus meiner
> Sicht kein zwingender Handlungsbedarf gegeben.
>
>
>
>> Die Partition soll daher etwas verkleinert werden.
>>
>> Wie mache ich das am besten?
>
> Wenn Du die Anpassung dennoch machen willst, würden mich noch folgende
> Sachen interessieren:
>
> Der Füllstand des Laufwerks, um den zeitlichen Rahmen abzuschätzen
>
> df md0
>
> und die Blockgrösse des Dateisystems
>
> tune2fs -l /dev/md0 | grep 'Block size'
# df /dev/md0
> Wenn Du die Anpassung dennoch machen willst, würden mich noch folgende
> Sachen interessieren:
>
> Der Füllstand des Laufwerks, um den zeitlichen Rahmen abzuschätzen
>
> df md0
>
> und die Blockgrösse des Dateisystems
>
> tune2fs -l /dev/md0 | grep 'Block size'
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 961433544 142717184 769878288 16% /data
# tune2fs -l /dev/md0 | grep "Block size"
Block size: 4096
> Bei Gelegenheit einen Blick auf die SMART Werte der Platten werfen, wäre
> auch nicht verkehrt.
Bevor ich entscheide ob ich das durchführe, möchte ich den Aufwand und
das Risiko abschätzen können. Bis dahin belasse ich den aktuellen Kernel
auf dem Server.
Grüße Rolf
Thomas Zweifel
May 13, 2016, 11:20:02 AM5/13/16
to
Hallo Rolf
Am 13.05.2016 um 16:31 schrieb Rolf Bensch:
>> Bei Gelegenheit einen Blick auf die SMART Werte der Platten werfen, wäre
>> auch nicht verkehrt.
>
> Das habe ich immer im Blick. Das Backup funktioniert auch zuverlässig :-))
Dann sieht das schon mal gut aus. ;-)
> Bevor ich entscheide ob ich das durchführe, möchte ich den Aufwand und
Wenn nichts wesentliches schief geht: ca. 3h
> das Risiko abschätzen können. Bis dahin belasse ich den aktuellen Kernel
> auf dem Server.
Du löst die Redundanz auf, solange die verbliebene Platte in dem Moment
nicht ausfällt, wird Dir der Griff zum Backup erspart bleiben. ;-)
Gruss Thomas
Am 13.05.2016 um 16:31 schrieb Rolf Bensch:
>> Bei Gelegenheit einen Blick auf die SMART Werte der Platten werfen, wäre
>> auch nicht verkehrt.
>
> Das habe ich immer im Blick. Das Backup funktioniert auch zuverlässig :-))
> Bevor ich entscheide ob ich das durchführe, möchte ich den Aufwand und
> das Risiko abschätzen können. Bis dahin belasse ich den aktuellen Kernel
> auf dem Server.
nicht ausfällt, wird Dir der Griff zum Backup erspart bleiben. ;-)
Gruss Thomas
Rolf Bensch
May 13, 2016, 12:15:21 PM5/13/16
to
Hallo Thomas,
Am 13.05.2016 um 17:12 schrieb Thomas Zweifel:
> Du löst die Redundanz auf, solange die verbliebene Platte in dem Moment
> nicht ausfällt, wird Dir der Griff zum Backup erspart bleiben. ;-)
dann ist alles im grünen Bereich (die Neugier siegt). Wie löst man die
Redundanz auf?
umount -l /data
mdadm --stop
und dann weiter?
Irgendwie müsste ich ja an eine der Partitionen auf den physikalischen
Laufwerken kommen, die sind aber type "Linux raid autodetect"....
Grüße Rolf
Am 13.05.2016 um 17:12 schrieb Thomas Zweifel:
> Du löst die Redundanz auf, solange die verbliebene Platte in dem Moment
> nicht ausfällt, wird Dir der Griff zum Backup erspart bleiben. ;-)
Redundanz auf?
umount -l /data
mdadm --stop
und dann weiter?
Irgendwie müsste ich ja an eine der Partitionen auf den physikalischen
Laufwerken kommen, die sind aber type "Linux raid autodetect"....
Grüße Rolf
Thomas Zweifel
May 13, 2016, 12:40:01 PM5/13/16
to
Hallo Rolf
Am 13.05.2016 um 18:15 schrieb Rolf Bensch:
> Am 13.05.2016 um 17:12 schrieb Thomas Zweifel:
>> Du löst die Redundanz auf, solange die verbliebene Platte in dem Moment
>> nicht ausfällt, wird Dir der Griff zum Backup erspart bleiben. ;-)
>
> dann ist alles im grünen Bereich (die Neugier siegt). Wie löst man die
> Redundanz auf?
>
> umount -l /data
> mdadm --stop
Falsch!
> und dann weiter?
Ich spiele es kurz durch, um nichts zu vergessen, hab solange noch
Geduld. ;-)
Gruss Thomas
Am 13.05.2016 um 18:15 schrieb Rolf Bensch:
> Am 13.05.2016 um 17:12 schrieb Thomas Zweifel:
>> Du löst die Redundanz auf, solange die verbliebene Platte in dem Moment
>> nicht ausfällt, wird Dir der Griff zum Backup erspart bleiben. ;-)
>
> dann ist alles im grünen Bereich (die Neugier siegt). Wie löst man die
> Redundanz auf?
>
> umount -l /data
> mdadm --stop
> und dann weiter?
Ich spiele es kurz durch, um nichts zu vergessen, hab solange noch
Geduld. ;-)
Gruss Thomas
Thomas Zweifel
May 13, 2016, 2:40:02 PM5/13/16
to
Hallo Rolf
Am 13.05.2016 um 16:31 schrieb Rolf Bensch:
> /dev/md0 /data ext4 defaults 0 0
>
> ibs-server # fdisk -l
Als erstes verkleinern wir das Dateisystem.
Da verkleinern nur Offline geht, müssen wir es aushängen. Dazu stoppst
Du alle Dienste welche auf md0 zugreifen, danach:
umount /data
und überprüfst es mit
e2fsck -f -C0 /dev/md0
Da etwa 140GiB belegt sind, verkleinern wir das Dateisystem auf 190GiB,
das Raid anschliessend auf 200GiB, der resysnc vom Raid wird dadurch
deutlich schneller erledigt sein.
resize2fs will die Grössenangabe in blöcken haben, also teilen wir die
190GB durch die Blockgrösse vom Dateisystem (4k)
--> 49807360 blöcke
resize2fs -p /dev/md0 49807360
Das dauert ca. 30-90min, je nachdem wie viel Daten umgelagert werden müssen.
Anschliessend den fsck nochmal drüber lassen:
e2fsck -f -C0 /dev/md0
Von hier an kann das Dateisystem wieder eingehängt werden, die
restlichen Schritte können während dem normalen Betrieb ausgeführt werden:
mount /data
und gegebenenfalls gestoppte Dienste wieder aktivieren.
Nun geht es ans verkleinern des Raids und neu partitionieren.
Zuerst schalten wir eventuell aktivierte bitmaps aus:
mdadm -G --bitmap=none /dev/md0
und verkleinern das Raid auf 200GiB
mdadm -G -z200G /dev/md0
Die folgenden Schritte führst Du nacheinander mit beiden Platten aus,
zuerst sdc danach für sdd:
Zuerst entfernen wir die Redundanz und löschen den Superblock:
mdadm --fail /dev/md0 /dev/sdc1
mdadm --remove /dev/md0 /dev/sdc1
mdadm --zero-superblock /dev/sdc1
den Erfolg kannst du mit:
cat /proc/mdstat
überprüfen.
Nun partitionieren wir die Platte:
fdisk /dev/sdc
Command (m for help): d
Selected partition 1
Partition 1 has been deleted.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-160836479, default 2048): 2048
Last sector, +sectors or +size{K,M,G,T,P} (2048-160836479, default
160836479): 160830000
Created a new partition 1 of type 'Linux' and of size 76.7 GiB.
Command (m for help): t
Selected partition 1
Partition type (type L to list all types): fd
Changed type of partition 'Linux' to 'Linux raid autodetect'.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Dies sind die Daten der 80GB Testplatte, Du wählst einen für die TB
Platte passenden Endsektor z.B. 1953520000 womit gut 2MB frei bleiben.
Mit:
cat /proc/partitions
überprüfen wir, dass die Partitionstabelle aktualisiert wurde.
Beim ersten Durchlauf sollte sdc1 etwas kleiner als sdd1 sein, beim
zweiten Durchlauf sind die Partitionen dann gleich gross.
Nun synchronisieren wir die angepasste Partition wider mit dem Raid
mdadm --add /dev/md0 /dev/sdc1
Der resync dauert etwa 45min. Den aktuellen fortschritt kannst Du dir mit
watch cat /proc/mdstat
anzeigen lassen. (CTRL-C/STRG-C zum beenden)
Jetzt ist die Zweite Platte an der Reihe, wiederhole das Ganze mit sdd.
So, nachdem die Partitionen nun ihre Zielgrösse haben und das
verkleinerte Raid synchronisiert ist, können wir das Raid und das
Dateisystem wieder vergrössern.
mdadm -G -zmax /dev/md0
vergrössert das Raid auf die ganze Partition, und
resize2fs -p /dev/md0
vergrössert das Dateisystem auf das ganze Raid.
Nachdem der resync vom restlichen Platz (ca. 700GiB) beendet ist, kannst
Du die bitmaps wieder einschalten:
mdadm -G --bitmap=internal /dev/md0
Damit wäre die Verkleinerung des Raids abgeschlossen.
Gruss Thomas
Am 13.05.2016 um 16:31 schrieb Rolf Bensch:
> Wie mache ich das am besten?
>
> fstab:
>
> /dev/md0 /data ext4 defaults 0 0
>
> ibs-server # fdisk -l
> Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Device Boot Start End Sectors Size Id Type
> /dev/sdc1 2048 1953525167 1953523120 931.5G fd Linux raid
>
> Device Boot Start End Sectors Size Id Type
> /dev/sdc1 2048 1953525167 1953523120 931.5G fd Linux raid
>
> Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> /dev/sdd1 2048 1953525167 1953523120 931.5G fd Linux raid
>
> /dev/sdd1 2048 1953525167 1953523120 931.5G fd Linux raid
>
> # df /dev/md0
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/md0 961433544 142717184 769878288 16% /data
>
> # tune2fs -l /dev/md0 | grep "Block size"
> Block size: 4096
Damit hätten wir alle Daten, die wir benötigen.
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/md0 961433544 142717184 769878288 16% /data
>
> # tune2fs -l /dev/md0 | grep "Block size"
> Block size: 4096
Als erstes verkleinern wir das Dateisystem.
Da verkleinern nur Offline geht, müssen wir es aushängen. Dazu stoppst
Du alle Dienste welche auf md0 zugreifen, danach:
umount /data
und überprüfst es mit
e2fsck -f -C0 /dev/md0
Da etwa 140GiB belegt sind, verkleinern wir das Dateisystem auf 190GiB,
das Raid anschliessend auf 200GiB, der resysnc vom Raid wird dadurch
deutlich schneller erledigt sein.
resize2fs will die Grössenangabe in blöcken haben, also teilen wir die
190GB durch die Blockgrösse vom Dateisystem (4k)
--> 49807360 blöcke
resize2fs -p /dev/md0 49807360
Das dauert ca. 30-90min, je nachdem wie viel Daten umgelagert werden müssen.
Anschliessend den fsck nochmal drüber lassen:
e2fsck -f -C0 /dev/md0
Von hier an kann das Dateisystem wieder eingehängt werden, die
restlichen Schritte können während dem normalen Betrieb ausgeführt werden:
mount /data
und gegebenenfalls gestoppte Dienste wieder aktivieren.
Nun geht es ans verkleinern des Raids und neu partitionieren.
Zuerst schalten wir eventuell aktivierte bitmaps aus:
mdadm -G --bitmap=none /dev/md0
und verkleinern das Raid auf 200GiB
mdadm -G -z200G /dev/md0
Die folgenden Schritte führst Du nacheinander mit beiden Platten aus,
zuerst sdc danach für sdd:
Zuerst entfernen wir die Redundanz und löschen den Superblock:
mdadm --fail /dev/md0 /dev/sdc1
mdadm --remove /dev/md0 /dev/sdc1
mdadm --zero-superblock /dev/sdc1
den Erfolg kannst du mit:
cat /proc/mdstat
überprüfen.
Nun partitionieren wir die Platte:
fdisk /dev/sdc
Command (m for help): d
Selected partition 1
Partition 1 has been deleted.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-160836479, default 2048): 2048
Last sector, +sectors or +size{K,M,G,T,P} (2048-160836479, default
160836479): 160830000
Created a new partition 1 of type 'Linux' and of size 76.7 GiB.
Command (m for help): t
Selected partition 1
Partition type (type L to list all types): fd
Changed type of partition 'Linux' to 'Linux raid autodetect'.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Dies sind die Daten der 80GB Testplatte, Du wählst einen für die TB
Platte passenden Endsektor z.B. 1953520000 womit gut 2MB frei bleiben.
Mit:
cat /proc/partitions
überprüfen wir, dass die Partitionstabelle aktualisiert wurde.
Beim ersten Durchlauf sollte sdc1 etwas kleiner als sdd1 sein, beim
zweiten Durchlauf sind die Partitionen dann gleich gross.
Nun synchronisieren wir die angepasste Partition wider mit dem Raid
mdadm --add /dev/md0 /dev/sdc1
Der resync dauert etwa 45min. Den aktuellen fortschritt kannst Du dir mit
watch cat /proc/mdstat
anzeigen lassen. (CTRL-C/STRG-C zum beenden)
Jetzt ist die Zweite Platte an der Reihe, wiederhole das Ganze mit sdd.
So, nachdem die Partitionen nun ihre Zielgrösse haben und das
verkleinerte Raid synchronisiert ist, können wir das Raid und das
Dateisystem wieder vergrössern.
mdadm -G -zmax /dev/md0
vergrössert das Raid auf die ganze Partition, und
resize2fs -p /dev/md0
vergrössert das Dateisystem auf das ganze Raid.
Nachdem der resync vom restlichen Platz (ca. 700GiB) beendet ist, kannst
Du die bitmaps wieder einschalten:
mdadm -G --bitmap=internal /dev/md0
Damit wäre die Verkleinerung des Raids abgeschlossen.
Gruss Thomas
Rolf Bensch
May 14, 2016, 7:20:16 AM5/14/16
to
Hallo Thomas,
da gibt es eine Menge zu tun, packen wirs' an:
Am 13.05.2016 um 20:34 schrieb Thomas Zweifel:
> ...
Hier kommt es zu einem Problem. sdc1 ließ sich noch problemlos
entfernen. Bei sdd1:
# mdadm --fail /dev/md0 /dev/sdd1
mdadm: set device faulty failed for /dev/sdd1: Device or resource busy
# mdadm --remove /dev/md0 /dev/sdd1
mdadm: hot remove failed for /dev/sdd1: Device or resource busy
# mdadm --zero-superblock /dev/sdd1
mdadm: Couldn't open /dev/sdd1 for write - not zeroing
entsprechend:
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4] [multipath]
md0 : active raid1 sdd1[1]
209715200 blocks [2/1] [_U]
unused devices: <none>
Wie weiter?
Grüße Rolf
da gibt es eine Menge zu tun, packen wirs' an:
Am 13.05.2016 um 20:34 schrieb Thomas Zweifel:
> ...
entfernen. Bei sdd1:
# mdadm --fail /dev/md0 /dev/sdd1
mdadm: set device faulty failed for /dev/sdd1: Device or resource busy
# mdadm --remove /dev/md0 /dev/sdd1
mdadm: hot remove failed for /dev/sdd1: Device or resource busy
# mdadm --zero-superblock /dev/sdd1
mdadm: Couldn't open /dev/sdd1 for write - not zeroing
entsprechend:
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4] [multipath]
md0 : active raid1 sdd1[1]
209715200 blocks [2/1] [_U]
unused devices: <none>
Wie weiter?
Grüße Rolf
Thomas Zweifel
May 14, 2016, 7:50:01 AM5/14/16
to
Hallo Rolf
Am 14.05.2016 um 13:20 schrieb Rolf Bensch:
> Hallo Thomas,
>
> da gibt es eine Menge zu tun, packen wirs' an:
>
> Am 13.05.2016 um 20:34 schrieb Thomas Zweifel:
>> ...
kommt nun dasselbe für sdd auszuführen. ;-)
>
> entsprechend:
> # cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
> [raid4] [multipath]
> md0 : active raid1 sdd1[1]
> 209715200 blocks [2/1] [_U]
>
> Wie weiter?
sdc hast Du aus dem Raid gekickt, jetzt geht es zuerst ans
partitionieren, anschliessend die Redundanz wieder aufbauen.
>> Jetzt ist die Zweite Platte an der Reihe, wiederhole das Ganze mit
>> sdd.
Erst wenn Du über diesen Hinweis stolperst, nimmst du dir sdd vor.
Gruss Thomas
Am 14.05.2016 um 13:20 schrieb Rolf Bensch:
> Hallo Thomas,
>
> da gibt es eine Menge zu tun, packen wirs' an:
>
> Am 13.05.2016 um 20:34 schrieb Thomas Zweifel:
>> ...
>> Die folgenden Schritte führst Du nacheinander mit beiden Platten aus,
>> zuerst sdc danach für sdd:
Du sollst die Schritte Komplett für sdc durchspielen, bis der Hinweis
>> zuerst sdc danach für sdd:
kommt nun dasselbe für sdd auszuführen. ;-)
>
> entsprechend:
> # cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
> [raid4] [multipath]
> md0 : active raid1 sdd1[1]
> 209715200 blocks [2/1] [_U]
>
sdc hast Du aus dem Raid gekickt, jetzt geht es zuerst ans
partitionieren, anschliessend die Redundanz wieder aufbauen.
>> Jetzt ist die Zweite Platte an der Reihe, wiederhole das Ganze mit
>> sdd.
Gruss Thomas
Marcus Roeckrath
May 14, 2016, 8:10:04 AM5/14/16
to
Hallo Rolf,
Rolf Bensch wrote:
>> Zuerst entfernen wir die Redundanz und löschen den Superblock:
>>
>> mdadm --fail /dev/md0 /dev/sdc1
>> mdadm --remove /dev/md0 /dev/sdc1
>> mdadm --zero-superblock /dev/sdc1
Du hast das erfolgreich für sdc1 durchgeführt.
> Hier kommt es zu einem Problem. sdc1 ließ sich noch problemlos
> entfernen. Bei sdd1:
>
> # mdadm --fail /dev/md0 /dev/sdd1
> mdadm: set device faulty failed for /dev/sdd1: Device or resource busy
> # mdadm --remove /dev/md0 /dev/sdd1
> mdadm: hot remove failed for /dev/sdd1: Device or resource busy
> # mdadm --zero-superblock /dev/sdd1
> mdadm: Couldn't open /dev/sdd1 for write - not zeroing
Das darfst Du an dieser Stelle auch nicht tun.
Erst alle weiteren Schritte für sdc1 und erst dann von vorne für sdd1.
--
Gruss Marcus
Rolf Bensch wrote:
>> Zuerst entfernen wir die Redundanz und löschen den Superblock:
>>
>> mdadm --fail /dev/md0 /dev/sdc1
>> mdadm --remove /dev/md0 /dev/sdc1
>> mdadm --zero-superblock /dev/sdc1
> Hier kommt es zu einem Problem. sdc1 ließ sich noch problemlos
> entfernen. Bei sdd1:
>
> # mdadm --fail /dev/md0 /dev/sdd1
> mdadm: set device faulty failed for /dev/sdd1: Device or resource busy
> # mdadm --remove /dev/md0 /dev/sdd1
> mdadm: hot remove failed for /dev/sdd1: Device or resource busy
> # mdadm --zero-superblock /dev/sdd1
> mdadm: Couldn't open /dev/sdd1 for write - not zeroing
Erst alle weiteren Schritte für sdc1 und erst dann von vorne für sdd1.
--
Gruss Marcus
Rolf Bensch
May 14, 2016, 1:31:02 PM5/14/16
to
Hallo Thomas,
ich hätte weiter lesen sollen - Du hast das sehr detailliert
beschrieben. Jetzt verstehe ich auch den gesamten Prozess. Coole Sache!
Im Moment läuft der erste recovery.
Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
wieder aktivieren können und das Raid sollte automatisch eingebunden
werden. Richtig?
Grüße Rolf
ich hätte weiter lesen sollen - Du hast das sehr detailliert
beschrieben. Jetzt verstehe ich auch den gesamten Prozess. Coole Sache!
Im Moment läuft der erste recovery.
Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
wieder aktivieren können und das Raid sollte automatisch eingebunden
werden. Richtig?
Grüße Rolf
Marcus Roeckrath
May 14, 2016, 1:50:02 PM5/14/16
to
Hallo Rolf,
Rolf Bensch wrote:
Rolf Bensch wrote:
> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
> wieder aktivieren können und das Raid sollte automatisch eingebunden
> werden. Richtig?
Ja, aber wozu der Aufwand die initrd wieder zu ändern?
> wieder aktivieren können und das Raid sollte automatisch eingebunden
> werden. Richtig?
Im neuen Kernel (2.21.0 testing) ist genau Deine manuelle Änderung offiziell
enthalten.
--
Gruss Marcus
Thomas Zweifel
May 14, 2016, 2:00:01 PM5/14/16
to
Hallo Rolf
Am 14.05.2016 um 19:31 schrieb Rolf Bensch:
>
> ich hätte weiter lesen sollen - Du hast das sehr detailliert
> beschrieben. Jetzt verstehe ich auch den gesamten Prozess. Coole Sache!
> Im Moment läuft der erste recovery.
Kaum macht man's richtig, schon Funktionierts! :-)
> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
> wieder aktivieren können und das Raid sollte automatisch eingebunden
> werden. Richtig?
Genau, ist aber nicht nötig.
Gruss Thomas
Am 14.05.2016 um 19:31 schrieb Rolf Bensch:
>
> ich hätte weiter lesen sollen - Du hast das sehr detailliert
> beschrieben. Jetzt verstehe ich auch den gesamten Prozess. Coole Sache!
> Im Moment läuft der erste recovery.
> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
> wieder aktivieren können und das Raid sollte automatisch eingebunden
> werden. Richtig?
Gruss Thomas
Rolf Bensch
May 15, 2016, 4:44:11 AM5/15/16
to
Hallo Marcus,
Am 14.05.2016 um 19:46 schrieb Marcus Roeckrath:
> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
>> wieder aktivieren können und das Raid sollte automatisch eingebunden
>> werden. Richtig?
>
> Ja, aber wozu der Aufwand die initrd wieder zu ändern?
nur um zu testen, ob der Raid-Verbund in anderen Umgebungen laufen
könnte. Ich habe noch ein Backup der initrd, so ist das kein Aufwand -
und bereits erfolgreich durchgeführt. (siehe weiter unten im Thread)
Grüße Rolf
Am 14.05.2016 um 19:46 schrieb Marcus Roeckrath:
> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
>> wieder aktivieren können und das Raid sollte automatisch eingebunden
>> werden. Richtig?
>
> Ja, aber wozu der Aufwand die initrd wieder zu ändern?
könnte. Ich habe noch ein Backup der initrd, so ist das kein Aufwand -
und bereits erfolgreich durchgeführt. (siehe weiter unten im Thread)
Grüße Rolf
Rolf Bensch
May 15, 2016, 4:54:12 AM5/15/16
to
Hallo Thomas,
es ist vollbracht. Unterm Strich war das eine spitzen-Anleitung!!!
# fdisk -l
...
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 1953520000 1953517953 931.5G fd Linux raid autodetect
Disk /dev/md0: 931.5 GiB, 1000201125888 bytes, 1953517824 sectors
normal. Auch nach dem Update auf 2.21.0 gibt es keine Auffälligkeiten.
Der Server ist maximal aktualisiert und läuft strörungsfrei. Vielen Dank
an alle Beteiligten für diese sehr lehrreiche Unterstützung!!!
Grüße Rolf
es ist vollbracht. Unterm Strich war das eine spitzen-Anleitung!!!
# fdisk -l
...
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 1953520000 1953517953 931.5G fd Linux raid autodetect
Device Boot Start End Sectors Size Id Type
Disk /dev/md0: 931.5 GiB, 1000201125888 bytes, 1953517824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Mit einer originalen initrd.gz aus Kernel 2.20.1 bootet das System
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
normal. Auch nach dem Update auf 2.21.0 gibt es keine Auffälligkeiten.
Der Server ist maximal aktualisiert und läuft strörungsfrei. Vielen Dank
an alle Beteiligten für diese sehr lehrreiche Unterstützung!!!
Grüße Rolf
Marcus Roeckrath
May 15, 2016, 5:00:02 AM5/15/16
to
Hallo Rolf,
Rolf Bensch wrote:
>>> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
>>> wieder aktivieren können und das Raid sollte automatisch eingebunden
>>> werden. Richtig?
>>
>> Ja, aber wozu der Aufwand die initrd wieder zu ändern?
>
> nur um zu testen, ob der Raid-Verbund in anderen Umgebungen laufen
> könnte. Ich habe noch ein Backup der initrd, so ist das kein Aufwand -
> und bereits erfolgreich durchgeführt. (siehe weiter unten im Thread)
Ok, das ist ein Grund und wenn er erfolgreich war, beruhigt das ungemein.
Rolf Bensch wrote:
>>> Wenn alles abgeschlossen ist, sollte ich die ungepatchte initrd.gz
>>> wieder aktivieren können und das Raid sollte automatisch eingebunden
>>> werden. Richtig?
>>
>> Ja, aber wozu der Aufwand die initrd wieder zu ändern?
>
> nur um zu testen, ob der Raid-Verbund in anderen Umgebungen laufen
> könnte. Ich habe noch ein Backup der initrd, so ist das kein Aufwand -
> und bereits erfolgreich durchgeführt. (siehe weiter unten im Thread)
Was alles garnicht so schlimm.
Thomas gute Anleitung könnte man doch mal (noch ein wenig ausgeschmückt) ins
Wiki stellen.
Hättest Du Lust dazu?
--
Gruss Marcus
Thomas Zweifel
May 15, 2016, 8:10:02 AM5/15/16
to
Hallo Rolf
Am 15.05.2016 um 10:54 schrieb Rolf Bensch:
>
> es ist vollbracht. Unterm Strich war das eine spitzen-Anleitung!!!
>
>
Gruss Thomas
Am 15.05.2016 um 10:54 schrieb Rolf Bensch:
>
> es ist vollbracht. Unterm Strich war das eine spitzen-Anleitung!!!
>
>
> Mit einer originalen initrd.gz aus Kernel 2.20.1 bootet das System
> normal. Auch nach dem Update auf 2.21.0 gibt es keine Auffälligkeiten.
>
> Der Server ist maximal aktualisiert und läuft strörungsfrei. Vielen Dank
> an alle Beteiligten für diese sehr lehrreiche Unterstützung!!!
Gern geschehen. :-)
> normal. Auch nach dem Update auf 2.21.0 gibt es keine Auffälligkeiten.
>
> Der Server ist maximal aktualisiert und läuft strörungsfrei. Vielen Dank
> an alle Beteiligten für diese sehr lehrreiche Unterstützung!!!
Gruss Thomas
Rolf Bensch
May 16, 2016, 11:01:03 AM5/16/16
to
Hallo NG,
nach Umsetzung wurde ein Beitrag im Wiki verfasst:
https://ssl.nettworks.org/wiki/x/1wGGAQ. Dieser enthält auch gemachte
Erfahrungen und etwas Hintergrundwissen.
Grüße Rolf
nach Umsetzung wurde ein Beitrag im Wiki verfasst:
https://ssl.nettworks.org/wiki/x/1wGGAQ. Dieser enthält auch gemachte
Erfahrungen und etwas Hintergrundwissen.
Grüße Rolf
Marcus Roeckrath
May 16, 2016, 11:20:03 AM5/16/16
to
Hallo Rolf,
Rolf Bensch wrote:
Rolf Bensch wrote:
> nach Umsetzung wurde ein Beitrag im Wiki verfasst:
> https://ssl.nettworks.org/wiki/x/1wGGAQ. Dieser enthält auch gemachte
> Erfahrungen und etwas Hintergrundwissen.
Vielen Dank dafür; klingt gut (ein winzige Korrektur der
> https://ssl.nettworks.org/wiki/x/1wGGAQ. Dieser enthält auch gemachte
> Erfahrungen und etwas Hintergrundwissen.
Kernelversionsnummer habe ich gemacht).
--
Gruss Marcus
Marcus Roeckrath
May 19, 2016, 12:20:03 AM5/19/16
to
Hallo Thomas,
Thomas Zweifel wrote:
Thomas Zweifel wrote:
> Die folgenden Schritte führst Du nacheinander mit beiden Platten aus,
> zuerst sdc danach für sdd:
[...]
> zuerst sdc danach für sdd:
>
> Nun partitionieren wir die Platte:
>
> fdisk /dev/sdc
[...]
> Nun partitionieren wir die Platte:
>
> fdisk /dev/sdc
>
> Jetzt ist die Zweite Platte an der Reihe, wiederhole das Ganze mit sdd.
Wäre es nicht sicherer, die Partitionierung der zweiten Platte von der
> Jetzt ist die Zweite Platte an der Reihe, wiederhole das Ganze mit sdd.
ersten zu üernehmen, wie es auch in der eisfair-Dokumentation für das
"Desaster Recovery" beschrieben ist:
sgdisk -R /dev/scd /dev/sdd
--
Gruss Marcus
Thomas Zweifel
May 19, 2016, 9:20:02 AM5/19/16
to
Hallo Marcus
Kann man machen, auch wenn es dadurch nicht "sicherer" wird, ist es
sicher einfacher und schneller. :-)
Gruss Thomas
sicher einfacher und schneller. :-)
Gruss Thomas
Thomas Bork
May 19, 2016, 10:29:56 AM5/19/16
to
Am 19.05.2016 um 06:11 schrieb Marcus Roeckrath:
> Wäre es nicht sicherer, die Partitionierung der zweiten Platte von der
> ersten zu üernehmen, wie es auch in der eisfair-Dokumentation für das
> "Desaster Recovery" beschrieben ist:
> sgdisk -R /dev/scd /dev/sdd
Neben Deinem Schreibfehler (/dev/scd statt /dev/sdc) hast Du hier auch
> ersten zu üernehmen, wie es auch in der eisfair-Dokumentation für das
> "Desaster Recovery" beschrieben ist:
> sgdisk -R /dev/scd /dev/sdd
noch einen logischen Fehler:
sgdisk -R
arbeitet anders herum. Wenn Du das Partitions-Layout von sdc auf sdd
übertragen willst, muss das so aussehen:
sgdisk -R /dev/sdd /dev/sdc
Siehe Dokumentation. So etwas kann mal eben unwiederbringliche Daten in
die digitale Kloake befördern. Und danach nicht vergessen:
sgdisk -G /dev/sdd
--
der tom
[eisfair-team]
Marcus Roeckrath
May 19, 2016, 11:30:03 AM5/19/16
to
Hallo Thomas,
Thomas Zweifel wrote:
>> sgdisk -R /dev/scd /dev/sdd
Thomas Zweifel wrote:
Wie Thomas schon schrieb:
sgdisk -R /dev/sdd /dev/sdc
und ein
sgdisk -G /dev/sdd
> Kann man machen, auch wenn es dadurch nicht "sicherer" wird, ist es
> sicher einfacher und schneller. :-)
Platte im Vergleich zur ersten vertut.
--
Gruss Marcus
Rolf Bensch
May 19, 2016, 11:32:03 AM5/19/16
to
Hallo Tom,
sollte man das neue HowTo dahingehend anpassen? Dein letzter Satz lässt
mich zögern. Die hier dargestellte Variante ist vielleicht eleganter,
die andere Variante birgt dieses Risiko nicht - wobei Änderung von
Partitions-Informationen grundsätzlich ein Risiko ist.
Grüße Rolf
sollte man das neue HowTo dahingehend anpassen? Dein letzter Satz lässt
mich zögern. Die hier dargestellte Variante ist vielleicht eleganter,
die andere Variante birgt dieses Risiko nicht - wobei Änderung von
Partitions-Informationen grundsätzlich ein Risiko ist.
Grüße Rolf
Thomas Bork
May 19, 2016, 12:05:21 PM5/19/16
to
auch in der eisfair-Dokumentation so beschrieben:
http://www.eisfair.org/fileadmin/eisfair/doc/node4.html#SECTION00423000000000000000
https://ssl.nettworks.org/repo/browse/eisfair/trunk/install/eisfair-1/eis-installer/opt/linuxrc2?r=41198
Meine Anmerkung bezog sich auch nur darauf, dass es äussert
kontraproduktiv sein kann, wenn man die Partitions-Informationen auf der
noch funktionstüchtigen Platte mit denen der nicht mehr
funktionstüchtigen überschreibt.
Man sollte sich also dringend merken:
sgdisk -R Ziel Quelle
--
der tom
[eisfair-team]
Marcus Roeckrath
May 19, 2016, 12:10:02 PM5/19/16
to
Hallo Rolf,
Rolf Bensch wrote:
Rolf Bensch wrote:
Die Anleitung bezog ja auch auf zwei baugleiche Platten, wobei es dann egal
ist, mit welcher man beginnt.
Es kann ja auch der Fall eintreten, dass die Platten verschieden groß sind,
wobei auf der größeren ja dann sowieso ein freier Bereich vorhanden ist.
Dann müsste man mit der kleineren - bis zum Rand partitionierten - Platte
anfangen und dann die - eigentlich unkritische - größere Platte behandeln.
--
Gruss Marcus
Marcus Roeckrath
May 19, 2016, 12:20:03 PM5/19/16
to
Hallo Thomas,
Thomas Bork wrote:
> Geschmackssache. Allerdings arbeitet sowohl der Installer so als ist es
> auch in der eisfair-Dokumentation so beschrieben:
>
http://www.eisfair.org/fileadmin/eisfair/doc/node4.html#SECTION00423000000000000000
Abschnitt "Desaster recovery" geschaut.
Das sollte als Hinweis auch dort mal prominent so als Hinweis aufgenommen
werden.
Man muss sich das dort aus den Codeschnipseln auch ganz genau ableiten; ein
falscher Blick und man fällt - wie ich heute morgen - eventuell rein.
--
Gruss Marcus
Thomas Bork wrote:
> Geschmackssache. Allerdings arbeitet sowohl der Installer so als ist es
> auch in der eisfair-Dokumentation so beschrieben:
>
http://www.eisfair.org/fileadmin/eisfair/doc/node4.html#SECTION00423000000000000000
> > Man sollte sich also dringend merken:
>
> sgdisk -R Ziel Quelle
Ich habe gerade nochmal in obige Dokumentation - und heute morgen in den
>
> sgdisk -R Ziel Quelle
Abschnitt "Desaster recovery" geschaut.
Das sollte als Hinweis auch dort mal prominent so als Hinweis aufgenommen
werden.
Man muss sich das dort aus den Codeschnipseln auch ganz genau ableiten; ein
falscher Blick und man fällt - wie ich heute morgen - eventuell rein.
--
Gruss Marcus
Thomas Zweifel
May 19, 2016, 1:50:02 PM5/19/16
to
Hallo Marcus
Am 19.05.2016 um 17:27 schrieb Marcus Roeckrath:
> Thomas Zweifel wrote:
>>
vergrössert wird. IMO kein grosses Drama.
Gruss Thomas
Am 19.05.2016 um 17:27 schrieb Marcus Roeckrath:
> Thomas Zweifel wrote:
>>
>> Kann man machen, auch wenn es dadurch nicht "sicherer" wird, ist es
>> sicher einfacher und schneller. :-)
>
> Verhindert, dass man sich bei der Eingabe der Sektoren bei der zweiten
> Platte im Vergleich zur ersten vertut.
Was dazu führt, dass das Raid nur bis zur kleineren Partition
>> sicher einfacher und schneller. :-)
>
> Verhindert, dass man sich bei der Eingabe der Sektoren bei der zweiten
> Platte im Vergleich zur ersten vertut.
vergrössert wird. IMO kein grosses Drama.
Gruss Thomas
Rolf Bensch
May 20, 2016, 10:31:26 AM5/20/16
to
Hallo Marcus,
Am 19.05.2016 um 18:03 schrieb Marcus Roeckrath:
> Vielleicht als Alternative für das Partitionieren der zweiten Platte?
ist erledigt.
Gruß Rolf
Am 19.05.2016 um 18:03 schrieb Marcus Roeckrath:
> Vielleicht als Alternative für das Partitionieren der zweiten Platte?
Gruß Rolf
0 new messages