SHR-1 nutzt Platz nicht optimal, obwohl offensichtlich möglich nach Analyse

[soeren487]

Moin Moin Community,

zu meinem Background: Ich bin studierter Informatiker, wir können also gerne ins Detail gehen Das gleich geschilderte Problem lässt sich auch definitiv per persönlichem Eingriff fixen, aber ich frage mich, warum das DSM dies nicht selbst in den Griff bekommt? - Eine ausgiebige Suche in den letzten Tagen ergab leider keine Treffer auf dieses doch sehr spezielle, mit vielen unterschiedlichen Größen von Platten zusammengewürfelte Problem. Im Folgenden sind alle Größenangaben der Einfachheit halber gerundet.

Umgebung:
Ich habe eine DS2415+, DSM 6.0 Build 732, Aktuelle Bestückung: Slot (1|2|3|4|5|6) 750GB, Slot (7|8) 1500GB, Slot (9|10|11|12) 2000GB. Da die DiskStation sehr frisch ist (Am 23.03.16 aufgestellt), wurde direkt DSM 6.0 installiert. Die 750GB Platten wurden nachträglich eingesetzt. Die Anfangskonfiguration: Slot (1) 500GB, Slot (2|3|4|5|6) 640GB, Slot (7|8) 1500GB, Slot (9|10|11|12) 2000GB. Es handelt sich bei allen Platten um WD, die jeweils auch vom gleichen Typ sind, also auch gleiche Anzahl an Sektoren.

Problembeschreibung:
Dazu das folgende Bild zur Veranschaulichung.

Bild: siehe Anhang.

Durch ein einfaches $fdisk -l bekommt man schnell heraus, wie die Partitionen auf den Platten verteilt sind und wie SHR-1 im Hintergrund funktioniert. Über $parted /dev/sd("a"|"b"|"c"|"d"|"e"|"f") findet man ebenfalls den verschwendeten Platz von 110GB pro 750GB Platte. Die Option im Storage Manager das Volume mit nicht-allokiertem Speicher zu erweitern ist und bleibt ausgegraut. Beim schrittweisen Austauschen der Platten hat das Wiederherstellen bei jedem Vorgang allerdings angegeben, dass das Volumen um 110GB erweitert werden wird (ab der 2. 750GB Platte verständlicherweise). Es tat sich im Nachhinein aber nichts. So kam bei Platte 2 die Angabe von 11.74TB, aber es blieben 11.63TB. Beim Tausch 3-6 genau die gleichen Angaben von jeweils 11.74TB. Insgesamt sollten eigentlich ca. 12.1TB zur Verfügung stehen.

Die Frage:
Weshalb schafft es das DSM nicht, über freien die 6x 110GB ein weiteres Raid 5 aufzuspannen, welches der Volume Group hinzugefügt wird und dann das Logical Volume in seiner Größe erweitern kann? Kann man dies mit DSM mitteln lösen, die auch später vom OS supported werden?

Per Hand kann man das definitiv lösen. Partitionen anlegen, als Raid 5 zusammenfassen, zur Volume Group hinzufügen und das Logical Volume erweitern. Aber das ist nicht Sinn der Sache hier händisch einzugreifen, weil dann im Nachhinein sicherlich Probleme mit DSM eintreten werden, wenn bspw. eine Platte ausfallen sollte und dann der Parity Check und der Rebuild kommt.

Vielen Dank für eure Kommentare und Gruß
Sören

 

[Puppetmaster]

Schöne Analyse!

Aber wer ausser dem Hersteller soll Dir jetzt die Frage beantworten, weshalb der DSM das nicht macht?

 

[Kurt-oe1kyw]

hmmmmmmmm, der Synology Calculator <klick> zeigt bei deiner Konfiguration als SHR eine Speicherkapazität von 12,7 TB und 2 TB werden für die Sicherheit benutzt.
Da ist eigentlich nicht ausgegraut, also als "unbenützter" Speicherplatz markiert:



Vielleicht betrügt uns Synology ja einfach nur

 

[soeren487]

@Puppetmaster: Danke für das Lob!

Ich denke, dass es wahrscheinlich noch mehr Nutzer gibt, die eine DS2415+ mit unterschiedlich gestückelten Festplatten gibt, die vielleicht vor dem gleichen Problem stehen.

Vielleicht ist es auch tatsächlich ein Bug von DSM 6.0? Mir ist aufgefallen, dass viele Tools, wie $lsof nicht mehr im System vorhanden sind. Auch ein $umount /volume1/ ist nur noch mit der Option lazy ("-l") möglich, $fsck.ext4 beschwert sich aber weiterhin, dass das Volume "/dev/vg1000/lv" unter Benutzung ist...

Mich würde also auch interessieren, ob es Anwender gibt, die auch unter DSM 5.0 dieses Problem hatten/haben.

Weiterhin basiert SHR auf LVM, welches nicht Synology-spezifisch ist. Vielleicht ist es hier, dass in der ausgeführten Reihenfolge ein Erweitern nicht möglich ist.

 

[dil88]

Wäre dennoch m.E. interessant, Synology darauf hinzuweisen und um eine Erklärung zu bitten.

 

[soeren487]

@Kurt-oe1kyw: Die 12.7TB beziehen sich ja auf die Berechnung der Größen mit dem Faktor 1000. Rechnet man dies mit Faktor 1024 um, landet man bei 11.55TB was auch ca. der Größe in Step 0 entsprach. Also das ist schon alles ganz richtig

 

[soeren487]

@dil88: Das ist auch der nächste Schritt, deshalb die Grafik bereits im Englischen. Ich werde die Anfrage nachher Absenden und hier auch die Anfragen/Antworten posten. Vielleicht hat ja dennoch jemand etwas in diese Richtung schon einmal gehabt.

 

[goetz]

Hallo,
warum die Erweiterung nicht stattfindet kann ich auch nicht sagen.
Problematik volume1 aushängen
syno_poweroff_task -d
vgchange -ay
Jezt muß man noch sein device finden, entweder unter /dev/vg oder /dev/mapper, volume1 sollte jetzt ausgehangen sein.

Gruß Götz

 

[soeren487]

@goetz: Auch diese Methode funktioniert bei mir unter DSM 6.0 nicht...

$syno_poweroff_task -d
$vgchange -ay vg1000
$fsck.ext4 -yvf -C0 /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
/dev/vg1000/lv is in use.
e2fsck: Cannot continue, aborting.

Das war mein einfacher erster Ansatz, um es schnell per Hand zu lösen. Wobei ich bezweifle ob es das Problem wirklich lösen würde.

Nebensächliche Erweiterung: Was mir gerade noch wieder in den Kopf kommt, $syno_poweroff_task -d macht kein $umount von /volume1/. Unter $df ist es weiter gemounted und auch erreichbar.

 

[goetz]

Hallo,
syno_poweroff_task -d sollte aber genau dies tun. Was mir aufgefallen ist, volume1 bleibt eingehangen wenn man als admin angemeldet ist und sich per sudo -i zum root macht. Melde ich mich direkt als root mit key authentication an wird auch volume1 ausgeworfen.

Using username "root".
Authenticating with public key "rsa-key-20120714"
root@DS1513:~# syno_poweroff_task -d
root@DS1513:~# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/md0         2385528 769412   1497332  34% /
none             2016980      4   2016976   1% /dev
/tmp             2021264    480   2020784   1% /tmp
/run             2021264   1648   2019616   1% /run
/dev/shm         2021264      4   2021260   1% /dev/shm
none                   4      0         4   0% /sys/fs/cgroup
root@DS1513:~#

Gruß Götz

 

[soeren487]

@goetz: Das ist interessant. Ich bin bisher über den weg SSH-Login als admin, dann "$sudo su" zu root gegangen. Hier ebenfalls das gleiche. Es wäre halt interessant einmal das $fsck.ext4... ans laufen zu bekommen. Denn ein Überprüfen ohne Änderungen gibt aus:

$fsck.ext4 -v -n -f /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
Warning! /dev/vg1000/lv is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 2391905 has zero dtime. Fix? no

Inodes that were part of a corrupted orphan linked list found. Fix? no

Inode 2391948 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -18878626 -18878778
Fix? no

Free blocks count wrong (855849039, counted=855848818).
Fix? no

Inode bitmap differences: -2391905 -2391948
Fix? no

Directories count wrong for group #583 (188, counted=186).
Fix? no

Free inodes count wrong (389911364, counted=389911331).
Fix? no


1.42.6-5644: ********** WARNING: Filesystem still has errors **********


351420 inodes used (0.09%, out of 390262784)
11766 non-contiguous files (3.3%)
233 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 345417/5700
2266222513 blocks used (72.59%, out of 3122071552)
0 bad blocks
623 large files

314584 regular files
36532 directories
0 character device files
0 block device files
0 fifos
0 links
326 symbolic links (326 fast symbolic links)
0 sockets
------------
351442 files

Dann konfiguriere ich heute Abend einmal den direkten Root-Login unter DSM 6.0.

 

[goetz]

Hallo,
bezüglich der Erweiterung des volumes, die DSM Hilfe besagt folgendes
"
Because SHR volumes optimize storage capacity based on the number and size of installed hard drives, please follow the below guidelines in order to properly expand capacity:
...

• If the capacity of existing hard drives is different, then the new, replacement hard drives must be equal to or larger than the largest existing hard drive. In addition, you must replace smaller hard drives first in order to optimize capacity usage. For example, if your SHR volume consists of three hard drives that are 4 TB, 3 TB, and 2 TB respectively, then your new, replacement hard drives must be at least 4 TB. In addition, you should replace the 3 TB or 2 TB hard drives first.

Gruß Götz

 

[soeren487]

Ich denke es hat gerade Klick im Kopf gemacht, weshalb dies so ist. Ich habe das ganze Spiel nicht zuende gedacht. Es wäre ohne weiteres möglich den verschenkten Platz als weiteres Raid 5 Array hinzuzufügen. Solange die Konfiguration so bleibt, ist auch alles gut. Werden aber erneut die 750GB Platten ausgetauscht, zum Beispiel gegen 2TB Platten, so muss die Reihe mit 110GB Partitionen erhalten bleiben. Dies würde dazu führen, dass die anderen Partitionen der bereits vorhandenen 2TB Platten nicht für die neuen Übernommen werden können. Somit müsste der freie Platz nach der 110GB Partition mit einer neuen Partitionsgröße allokiert werden, was zu einem weiteren Raid 5 Array führen würde. Bei weiterem Austauschen, würde dieses Spiel immer und immer weiter fortgeführt werden und man hat ein unglaubliches Gemetzel aus unterschiedlichsten Raid 5 Partitionen, die das LVM zusammenfassen muss. Die von @goetz zitierte Taktik will dafür sorgen, dass möglichst wenige, neue Partitionen erschaffen werden müssen.

Pragmatische Lösung: 8x 2TB Platten rein und alles als Raid 5 oder dann sogar Raid 6 konfigurieren. Folglich hat man auch dieses Partitions-Geraffel durch SHR nicht.

Dennoch werde ich jedenfalls versuchen, die eben gezeigten Fehler des Logic Volumes zu beheben. Müssen ja nicht da sein

 

[dil88]

Vielleicht interessiert Dich in diesem Zusammenhang dieser Thread und insbesondere der dort eingangs verlinkte Artikel.

 

[soeren487]

@dil88: Das trifft den Nagel auf den Kopf und ist mir leider vorhin erst bewusst geworden.

SHR ist praktisch, wenn man eine bleibende Konfiguration von Festplatten unterschiedlicher Größe hat, sobald man anfängt durchzutauschen, wird es unter der Haube aber echt hässlich...

 

[soeren487]

@goetz: Vielen Dank für den Hinweis mit dem direkten Login als root. Dann funktioniert es tatsächlich mit dem Aushängen des Volumes durch $syno_poweroff_task -d und fsck kann nach dem $vgchange -ay vg1000 problemlos arbeiten.

 

[Puppetmaster]

Danke @dil88, an den Artikel musste ich auch gleich denken, aber ich habe ihn nicht mehr gefunden, da mir die korrekten Schlagworte nicht präsent waren.