Sie sind hier : Homepage →  Linux (6) Ein Webtropia root-Server→  Der Webtropia Rescue-Modus→  Auf 13.2 (webtropia) aufbauen.→  RAID Partition verkleinern

Das vorhandene Grund-System soll korrigiert werden.

Januar 2017 - Die webtropia Partitionierung der opensuse 13.2 Festplatte, also der Partitionierung der webtropia Grund-Installation, ist für einen SAMBA Server sicherlich ok, wenn auch unglücklich. Der Profi trennt immer sein Betriebssystem von den Daten-Partitionen. Für uns ist es so jedenfalls (auch) nicht sinnvoll. Wir wollen auf dem Server kleine 60GB VMs virtualisieren. Und dazu soll die 922 GB Partiton erheblich verkleinert werden. Für den Hypervisor sind bereits 22GB recht viel, doch etwas Reserve kann nie schaden.

.

Die Aufgabe : Eine gesunde RAID1 Partition verkleinern . . .

Die wichtigste Aufgabe bei dieser webtropia opensuse Installation ist es, aus der 922 GB Partition eine nur noch 22 GB große root-Partition unter Beibehalt der UUID (nur wenn möglich) und des Filesystems (des Inhaltes) zu machen. Da ist jetzt unser funktionierendes root Filesystem drinnen und das brauchen wir noch.
.

  • Vorausschau gleich hier : Bei uns geht das so nicht, die 922GB Partiton ist für die "grow" Option (shrinking = verkleinern) mit dem aktuellen mdadm ("multiple disk administration" Programm) scheinbar zu groß. Das müssen wir noch austesten.

.

Erst mal schaun, was auf der 2 x 1TB Platte "drinnen" ist

[xen9-]~ $ df -h            
Dateisystem Größe Benutzt Verfügb. Verw.in % Eingehängt auf  
/dev/md1 2,0G 56M 1,8G 3% /boot  
/dev/md2 1,8T 2,3G 1,7T 1% /  
             
devtmpfs 16G 8,0K 16G 1% /dev  
tmpfs 16G 0 16G 0% /dev/shm  
tmpfs 16G 1,9M 16G 1% /run  
tmpfs 16G 0 16G 0% /sys/fs/cgroup  


Diie Anzeige stimmt nicht, weil dort die physikalischen Platten aufsummiert werden. Also bei den Angaben von md1 und von md2 nur die Hälfte der Werte betrachten.
.

Hier eine Anleitung eines Versuchs, unsere mit nur 3GB Daten gefüllte RAID1 922GB Partition zu verkleinern :

Auf jeden Fall (und ohne Ausnahme) muß eine Komplett-Sicherung der Partition(en) erstellt werden und zwar mit "tar" wegen der symbolischn Links und der Owner und der Rechte

Dazu schaun wir mit gparted auf diese Partition und merken uns den "Füllstand" und die Bruttogrösse als Anhaltspunkt.

Bei unserem Problem ist es einfach. Ich habe 922 Giga als md2 und möchte aber nur 22 Giga. Zur Zeit werden da auch nur 2,3 Giga als root System benutzt. Also bin ich mit 22 Giga auf der absolut sicheren Seite.
.

Die Vorbereitung des Rescue Systems für Datensicherung/VNC

aptitude update
aptitude install joe


Anmerkung : zum Aufrufen grafischer Tools braucht man bei debian keinen separaten x11 oder Xorg- Server - das macht alles dieser Server hier :
aptitude install tightvncserver

Die Prüfung auf Partitionen:
root@grml /etc # ls -l /dev/disk/by-uuid
total 0
root root 9 Jan 10 21:59 652a2a86-65cb-425c-9760-bba641245f0d -> ../../md2
root root 9 Jan 10 21:59 77506b7e-c0d2-4712-8461-e94f0ffe1c78 -> ../../md1
root root 9 Jan 10 21:59 f735ff65-bc3c-4685-b987-204b3a5a97aa -> ../../md0

Das sieht gut aus, die RAID1 Partitionen sind also schon erkannt.

Jetzt kommt das Mounten der beiden ext4 Partitionen zwecks Sicherung.

root@grml /etc # cd /

root@grml / # mkdir mnt1
root@grml / # mkdir mnt2
root@grml / # mount /dev/md1 /mnt1
root@grml / # mount /dev/md2 /mnt2
root@grml / #

die Partitionsgrößen anzeigen lassen

root@grml / # lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT

sda       8:0    0 931,5G  0 disk
-> -> sda1    8:1    0     8G  0 part
->  -> -> md0   9:0    0    16G  0 raid0
-> -> sda2    8:2    0     1G  0 part
->  -> -> md1   9:1    0     2G  0 raid0 /mnt1
-> -> sda3    8:3    0 922,5G  0 part
  -> -> md2   9:2    0   1,8T  0 raid0 /mnt2

sdb       8:16   0 931,5G  0 disk
-> -> sdb1    8:17   0     8G  0 part
->  -> -> md0   9:0    0    16G  0 raid0
-> -> sdb2    8:18   0     1G  0 part
->  -> -> md1   9:1    0     2G  0 raid0 /mnt1
-> -> sdb3    8:19   0 922,5G  0 part
  -> -> md2   9:2    0   1,8T  0 raid0 /mnt2

loop0     7:0    0 420,2M  1 loop  /lib/live/mount/rootfs/grml64-full_testing.squashfs
.

Wieviel Platz ist im lokalen RAM verfügbar ?

Wir wollen die beiden wichtigen ext4 Partitionen mit tar.gz in Archive packen und lokal zum Abholen mit winscp bereitstellen.

root@grml / # df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           6,3G  668K  6,3G   1% /run
/dev/loop0      421M  421M     0 100% /lib/live/mount/rootfs/grml64-full_testing.squashfs
tmpfs            16G     0   16G   0% /lib/live/mount/overlay
aufs             16G  154M   16G   1% /
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
devtmpfs         10M     0   10M   0% /dev
tmpfs           6,3G     0  6,3G   0% /run/shm
/dev/md1        2,0G   56M  1,8G   3% /mnt1
/dev/md2        1,8T  2,3G  1,7T   1% /mnt2

Auf dem temporären "temp-Filesystem" (im RAM) sind also 6,3GB verfügbar. Das ist für unsere Sicherung völlig ausreichend.

Beide Partitionen in /tmp/ sichern:

Beide Partitionen sind gemountet, also :

tar cfvz /tmp/2017-01-10-XEN9-suse-13-2-boot-partition.tar.gz /mnt1/
und
tar cfvz /tmp/2017-01-10-XEN9-suse-13-2-root-partition.tar.gz /mnt2/

fertig : tar cfvz /tmp/2017-01-10-XEN9-suse-13-2-root-partition.tar.gz /mnt2/  71,72s user 3,86s system 48% cpu 2:36,53 total
.

Die Sicherung ist auf dem lokalen NAS angekommen - ok

Wie oben gesagt, transferiere ich diese Sicherung Nachause in unser Büro auf das NAS System.
.

Die beiden Partitionen wieder frei geben mit "umount"

root@grml / # umount /mnt1
root@grml / # umount /mnt2
und mit
mount prüfen. Kein md1 bzw. md2 mehr zu sehen.
.

Jetzt geht es weiter mit gparted über VNC

gparted unter debian kann auf der grafischen Oberfläche angeblich auch RAID1 Partitonen z.B. unsere "md2" verkleinern (shrinken). Die Screenshots zeigen, daß ich von 1,8 Tera (echte 922GB) auf 110 GB (echte 55GB) verkleinern "will". (Eigentlich wollte ich nur 22GB haben.) Mal sehen, wie das im Ergebnis aussieht und was da raus kommt. Wir haben ja die Sicherung und auch die UUIDs gesichert.

Die jetzt neue "unallocatet Partition" von 1,7TB (rechts im Bild) wird später eine extended Partition (md3) werden. Daß später natürlich die echte verfügbare Größe angezeigt wird, ist sicher verständlich. Beim Verlassen zeigt gparted verwirrendes Zeug an. Also mal sehen.
.

Jetzt die Überprüfung: Die Operation hat NICHT geklappt.

Also den Rescue Modus beenden und die opensuse 13.2 vonPlatte starten. Zumindest startet das boot-System wieder. Es ist also scheinbar noch nichts kaputt gegangen. Doch die 3. Partition "md2" ist immer noch 922 GB groß. gparted hat die Partition irgendwie von der falschen Seite her verkleinert. Wie auch immer ........

Da hatte also nicht geklappt, die RAID1 Partition (besser gesagt das Filesystem) ist zwar innen drinnen verkleinert worden, aber nur halb und nicht so richtig. Jetzt gehts wieder zurück in den Rescue-Mode und es kommt die Commandline basierte Version vom Verkleinern von Falko Timme zum Einsatz
.

Author Falko Timme schreibt als Anleitung :

https://www.howtoforge.com/how-to-resize-raid-partitions-shrink-and-grow-software-raid

Absatz 2.1 Shrinking an intact array

I will describe how to resize the array /dev/md2, made up of /dev/sda3 and /dev/sdb3.

Boot into your rescue system and activate all needed modules:

modprobe md (was macht das ??)
modprobe raid1 (das müsste bei uns bereits aktiv sein)
.
Die RAID1 Konfiguration sichern (ob das auch bei unserem Debian geht ??):

cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf_orig
mdadm --examine --scan >> /etc/mdadm/mdadm.conf

e2fsck -f /dev/md2

ich muss es probieren...... ist noch nicht fertig..... usw.

Hier die abgeänderte oder ergänzte Version

Wir haben den webtropia root server und das webtropia Rescue System, das wir starten müssen.

Bei uns besteht das RAID1 = md2 auch aus sda3 und sdb3. Warum auch immer werden RAIDs ab 0 gezählt, Platten aber ab 1. Wir haben nur md und RAID1 : darum :

root@grml ~ # modprobe md
root@grml ~ # modprobe raid1

root@grml ~ # e2fsck -f /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 73549/120922112 files (1.9% non-contiguous), 8147076/483657722 blocks

/dev/md2 has (bei mir) a size of 922B; I want to shrink it to 30GB. First we have to shrink the file system with resize2fs; to make sure that the file system fits into the 30GB, we make it a little bit smaller (25GB) so we have a little security margin, shrink /dev/md2 to 30GB, and the resize the file system (again with resize2fs) to the max. possible value:

root@grml / # resize2fs /dev/md2 25G
resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on /dev/md2 to 6553600 (4k) blocks.
The filesystem on /dev/md2 is now 6553600 (4k) blocks long.
.
Now we shrink the Partition /dev/md2 to 30GB. The --size value must be in KiBytes (30 x 1024 x 1024 = 31457280); make sure it can be divided by 64:
.
root@grml / # mdadm --grow /dev/md2 --size=31457280
mdadm: Cannot set device size in this type of array.
.

Error : mdadm: Cannot set device size in this type of array.

.

  • Der mdadm will oder kann nicht. Ich vermute nach stundenlangem Googeln, keiner hatte es je mit so großen Brocken probiert und es ist ein Frage der Partitionsgröße.

.
Darum überprüfe ich nochmals das verkleinerte Filesystem :

1 root@grml / # e2fsck -f /dev/md2                                                                                                            :(
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 73549/1638400 files (1.9% non-contiguous), 654522/6553600 blocks
.

  1. Das FS ist schon erheblich kleiner geworden - aber :
  2. Warum geht das nicht da oben mit der Partition ???
  3. Ist das überhaupt notwendig ??
  4. Wie bekomme ich die Partition kleiner ?


Also noch ist zwar das Filesystem verkleinert worden, aber die Partition md2 ist nach wie vor 922 GB.
.

Überprüfung der Partition :


root@grml / # mdadm -D /dev/md2 | grep -e "Array Size" -e "Device Size"
     Array Size : 1934630888 (1845.01 GiB 1981.06 GB)

Die Partition md2 ist immer noch 1,8 TB groß natürlich durch 2 geteilt.

Noch ein Versuch mit enem Beispiel aus dem Lehrbuch :
mdadm --grow /dev/md2 -z 41943168 - das wäre 40GB

das geht aber auch nicht :

root@grml / # mdadm --grow /dev/md2 -z 41943168
mdadm: Cannot set device size in this type of array.

nochmals Kontrolle der intakten RAID1 Partitions :

1 root@grml / # cat /proc/mdstat                                                                                                              :(
Personalities : [raid0] [raid1]
md0 : active raid0 sdb1[1] sda1[0]
      16785384 blocks super 1.0 4k chunks

md1 : active raid0 sdb2[1] sda2[0]
      2105320 blocks super 1.0 4k chunks

md2 : active raid0 sdb3[1] sda3[0]
      1934630888 blocks super 1.0 4k chunks
.

Es ist etwas faul ?? Ich kann nicht auf 30GB verkleinern ??

Dieser Befehl - die Option "grow" funktioniert hier nicht :

mdadm --grow /dev/md2 --size=31457280
Ergebnis :
mdadm: Cannot set device size in this type of array.

in der Manpage steht :

  • SIZE CHANGES
    Normally when an array is built the "size" is taken from the smallest of the drives. If all the small drives in an arrays are, one at a time, removed and replaced with larger drives, then you could have an array of large drives with only a small amount used. In this situation, changing the "size" with "GROW" mode will allow the extra space to start being used. If the size is increased in this way, a "resync" process will start to make sure the new parts of the array are synchronised.
  • Note that when an array changes size, any filesystem that may be stored in the array will not automatically grow or shrink to use or vacate the space. The filesystem will need to be explicitly told to use the extra space after growing, or to reduce its size prior to shrinking the array.
  • Also the size of an array cannot be changed while it has an active bitmap. If an array has a bitmap, it must be removed before the size can be changed. Once the change is complete a new bitmap can be created.

.

und hier steht der einzige im Internet gefundene - super aktuelle - Sourcecode (vom 9.1.2017 !!!!) der "grow" Option von mdadm :

https://fossies.org/linux/mdadm/Grow.c

mit der obigen Fehlermeldung.

Hier zur Info die mdadm Optionen: (die aber auch nicht weiter helfen)

root@grml / # mdadm --help-options

Any parameter that does not start with '-' is treated as a device name or, for --examine-bitmap, a file name. The first such name is often the name of an md device.  Subsequent names are often names of component devices.
.
Some common options are:
 --help -h : General help message or, after above option,
 mode specific help message
 --help-options : This help message
 --version -V : Print version information for mdadm
 --verbose -v : Be more verbose about what is happening
 --quiet -q : Don't print un-necessary messages
 --brief -b : Be less verbose, more brief
 --export -Y : With --detail, --detail-platform or --examine use
 key=value format for easy import into environment
 --force -f : Override normal checks and be more forceful

 --assemble -A : Assemble an array
 --build -B : Build an array without metadata
 --create -C : Create a new array
 --detail -D : Display details of an array
 --examine -E : Examine superblock on an array component
 --examine-bitmap -X: Display the detail of a bitmap file
 --examine-badblocks: Display list of known bad blocks on device
 --monitor -F : monitor (follow) some arrays
 --grow -G : resize/ reshape and array
 --incremental -I : add/remove a single device to/from an array as appropriate
 --query -Q : Display general information about how a
 device relates to the md driver
 --auto-detect : Start arrays auto-detected by the kernel

root@grml / # mdadm --version
mdadm - v3.3.2 - 21st August 2014
root@grml / #

Auf der Entwicklerseite ist bereits die Version vom Januar 2017 verfügbar. Ob die es besser macht ??
.

gparted 0.19.0 - update auf 0.27.1 fehlgeschlagen, geht nicht

Mit dem gparted 0.19 ließ sich die Partition shrinken, aber auch nur vordergründig.
.
Laut der Entwickler soll die neue Version 0.27.1 vom Dez. 2016 das jetzt können, doch die ist auf dem alten webtropia Rescue-System (Kurzform : stretch/sid) nicht zu installieren. Zu viele Abhängigkeiten müssten mit großem Aufwand installiert werden. Und ein YAST gibts bei debian nicht.

Das Thema ist noch nicht beendet.
.

Dieser Weg hilft zur Zeit nicht weiter !!!!!!

Jetzt gibt es nur noch eines, das Ganze auszuprobieren - auf unserem Muster-Server hier im EDV Labor.

Zurück zur Startseite ----- © 2009 / 2018 - Copyright by Dipl. Ing. Gert Redlich - Zum Telefon - - - - NEU : Zum Flohmarkt