Plusieurs Volumes Sur Un M

[BenT]

Salut à tous,

j'ai intitulé ce message ainsi après avoir lu celui-ci dans lequel fredlime indique :

Non, pas possible de faire un volume supplémentaire sur un disque déjà utilisé.

S'il reste de l'espace, c'est perdu.

Dommage, c'est exactement ce que j'ai envie de faire... et j'y suis partiellement parvenu.

Explications :

- j'ai un DS107 avec 500Go et un DS207+ avec 2x750Go en RAID1.

- j'ai acheté un DD de 1,5To pour "cascader" un des 750Go sur le DS107, et avoir sur le DS207+ un /volume1 de 750Go en RAID1 et un /volume2 "basique", où je pourrai par exemple faire des copies quotidiennes des données du DS107.

C'est certes un peu tordu, mais ça me permet(trait) de faire un upgrade de capa non négligeable (quasi x2) par l'achat d'un unique disque.

Voici comment je m'y suis pris :

1/ j'ai éteint le DS207+, j'ai remplacé le disque 1 par le disque de 1,5To, j'ai rallumé ; je me suis connecté rapidement à DSM jusqu'à la page "Volume" pour couper l'alarme sonore...

2/ j'ai fait une première reconstruction à partir de la page "Volume"

Intérêt : ne pas se prendre la tête pour la partie système (les /dev/md0 et /dev/md1)

3/ je me suis occupé de la partition RAID1:

3.1/ j'ai resorti le disque du groupe RAID :

DS> mdadm /dev/md2 -f /dev/sda3 -r /dev/sda3

ce qui a provoqué la même alarme sonore qu'au premier redémarrage après l'ajout du disque. 3.2/ j'ai retaillé la partition 3 avec fdisk

DS> fdisk /dev/sda

[...]

DS> fdisk -l /dev/sdb


Disk /dev/sdb: 750.1 GB, 750156374016 bytes

255 heads, 63 sectors/track, 91201 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes


 Device Boot	Start 	End	Blocks Id System

/dev/sdb1 	1 	310 	2490043+ fd Linux raid autodetect

/dev/sdb2 	311 	375 	522112+ fd Linux raid autodetect

/dev/sdb3 	392 	91201 729431325 fd Linux raid autodetect

DS> fdisk -l /dev/sda


Disk /dev/sda: 1500.3 GB, 1500301910016 bytes

255 heads, 63 sectors/track, 182401 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes


 Device Boot	Start 	End	Blocks Id System

/dev/sda1 	1 	310 	2490043+ fd Linux raid autodetect

/dev/sda2 	311 	375 	522112+ fd Linux raid autodetect

/dev/sda3 	392 	91201 729431325 fd Linux raid autodetect

/dev/sda4 	91202 	182401 732564000 fd Linux raid autodetect

3.3/ puis je l'ai remise dans le groupe RAID :

DS> mdadm /dev/md2 -a /dev/sda3

et la reconstruction s'est lancée seule, visible via mdadm --query --detail /dev/md2 ou dans DSM. 4/ J'ai ensuite créé un nouveau groupe RAID (pour être homogène, en espérant que DSM s'y retrouverait tout seul comme un grand) :

DS> mdadm --create /dev/md3 --level=0 --force --raid-devices=1 /dev/sda4

mdadm: array /dev/md3 started.

DS> mdadm --query --detail /dev/md3

/dev/md3:

 	Version : 00.90.03

 Creation Time : Sat Oct 10 18:01:12 2009

 	Raid Level : raid0

 	Array Size : 732563904 (698.63 GiB 750.15 GB)

 Raid Devices : 1

 Total Devices : 1

Preferred Minor : 3

	Persistence : Superblock is persistent


	Update Time : Sat Oct 10 18:01:28 2009

 	State : active

 Active Devices : 1

Working Devices : 1

 Failed Devices : 0

 Spare Devices : 0


 	Chunk Size : 64K


 	UUID : 82cf73ed:0e05deb0:254e3236:2daf9462

 	Events : 0.3


	Number Major Minor RaidDevice State

 	0 	8 	4 	0 	active sync /dev/hda4

Le paramètre --force est indispensable, sinon mdadm met un petit commentaire du style "un seul disque dans un groupe RAID ça n'est pas banal, je ne le fais pas" 5/ J'ai enfin créé le FS puis monté tout le bazar :

DS> mkfs.ext3 /dev/md3

[...]

DS> mkdir /volume2

DS> vi /etc/fstab

/dev/root / ext3 defaults 1 1

none /proc proc defaults 0 0

/dev/md2 /volume1 ext3 defaults 0 0

/dev/md3 /volume2 ext3 defaults 0 0

DS> mount /volume2 

Le résultat de tout çà ?

DSM a l'air de s'y retrouver : dans la page "Statut", on voit bien le second volume et l'espace disponible, et dans la page "Dossiers partagés" il est possible d'y créer des partages.

En revanche, la page "Volume" ne présente pas le volume en question... et j'avoue que c'est ce qui me fait craindre le pire !

Suis-je en train de prendre de gros risques pour mes données ? Quelqu'un a-t-il un avis circonstancié sur la question ?

[fredlime]

j'ai intitulé ce message ainsi après avoir lu celui-ci dans lequel fredlime indique :

Dommage, c'est exactement ce que j'ai envie de faire... et j'y suis partiellement parvenu.

...

...

Suis-je en train de prendre de gros risques pour mes données ? Quelqu'un a-t-il un avis circonstancié sur la question ?

Bonjour,

Bien mes propos portaient sur les possibilités du firmware existant.

Sans me défiler, c'est certain qu'avec le systeme aussi ouvert que l'on a sur le SYNO, on peut le faire.

Et je vois que tu y es arrivé, bravo. Vraiment ...

Mais étais-tu vraiment obligé de casser ton RAID avant l'ajout de la partition ?

Le simple démontage du volume, pour libérer le disque et en stoppant tous les services, n'était pas suffisant ?

Maintenant, pour ton probleme de volume visible, il me semble qu'il y a un fichier qui les liste.

J'avais découvert cela a une époque, faudrait que je retombe sur mes notes. Si je les retrouve, je te fais signe

A+

Fred.

[BenT]

Merci pour ta réponse ; je continue de chercher de mon côté aussi, mais tes notes seront appréciées.

Car en fait je crois que j'ai / je vais avoir plus de soucis que ce que j'imaginais...

Je n'avais pas redémarré le Syno avant de poster mon message, maintenant je l'ai fait, et voici les dernières surprises du front :

1/ mon /etc/fstab a été écrasé

Bon, j'ai compris en lisant par exemple ce post que c'était "normal", au cours de l'exécution de /etc/rc (et AVANT le montage des FS) il y a un appel à /usr/syno/cfgen/s*, dont s00_synocheckfstab...

Dans le post en question, il y a bien des suggestions de modif de /etc/rc, mais ça me paraît aller encore un peu plus dans la recherche des ennuis (j'en tremble d'avance en pensant à la prochaine mise à jour de firmware... ).

Je vais surement "tuner" le truc dans /etc/rc.local, et éventuellement interdire l'exécution de s00_synocheckfstab.

Toute suggestion est la bienvenue...

2/ mon /var/log/messages est maintenant spammé de :

scemd: raid_decide_raid_disk_status.c(68) failed to get disk device name for major=8, minor=4

Et ce même après avoir remonté (avec succès) mon /dev/md3 sur /volume2. La seule référence à ce problème que Google m'ait trouvé est ce post ; mais il ne m'a pas beaucoup aidé sur la résolution (l'auteur parle de remonter en ext2, ce que je ne souhaite pas faire !! ou alors je n'ai rien compris...) Tout coup de main sur la question est plus que bienvenu aussi... Allez, j'y retourne... Au passage, voici un extrait de /usr/syno/sbin/synolvm_mklv qui donne la "bonne" méthode pour créer et monter le FS :

MkfsAndMount() { #{{{ $1: /dev/xxx $2: /volumeX

 	mkfs.ext3 $1

 	mount -o rw,usrquota,grpquota $1 $2

 	quotacheck -c -g -u -F vfsv0 $2

 	quotaon -F vfsv0 $2

 	mkdir "$2/@tmp"


 	grep -v $2 /etc/fstab > /tmp/fstab.tmp

 	echo "$1 $2 ext3 defaults 0 0" >> /tmp/fstab.tmp

 	mv /tmp/fstab.tmp /etc/fstab


 	echo "#Start services..."

 	for s in `ls /usr/syno/etc/rc.d/S*.sh`; do

 	$s start > /dev/null 2>&1

 	done

} #}}}

[BenT]

Petit update : en fait mon /var/log/messages est spammé depuis cette nuit, donc avant le reboot...

J'ai donc mené ma petite enquête ; sur le web, rien, mais dans les scripts du syno, pas mal de choses.

Le plus intéressant : /etc/newdisk.sh, qui semble indiquer que la "bonne" méthode passe par l'utilisation de raidtool (/usr/syno/bin/raidtool) au lieu de mdadm directement...

Le meilleur signe en est :

DS> raidtool status 3

/dev/md3 : status failed

alors que :

DS> raidtool status 2

RAID1, running, status: NORMAL r: NORMAL

 Disk:1 2 

 Failed disk: 

Device name: /dev/md2

Device size: 746937581568 1k-blocks 

Mounted: /volume1

Ceci dit, les commandes raidtool de newdisk.sh me font un peu froid dans le dos... et je ne voudrais pas perdre mes données dans /volume1 ! J'ai tenté ceci :

DS> raidtool destroy 3

destroy failed

DS> raidtool newvol 

raidtool.c(158)volume creation failed 0 : failed to init disk 1

Sans résultat donc... Encore une fois, toute suggestion bienvenue !

Autre piste : l'option "--name=" de mdadm aurait-elle éventuellement pu éviter les messages ? Le souci c'est que je n'ai pas trouvé comment utiliser l'option a posteriori ; je suis preneur d'une méthode (y compris passant par le "nettoyage par le vide" de mon /dev/md3, que je ne parviens pas à faire - sorry, pas un pro des groupes RAID).

[fredlime]

Bonsoir,

Désolé de te laisser chercher seul. J'suis un peu bousculé en ce moment , comme d'hab.....

Et puis, faudrait que je me libère mon SYNO rack pour faire des tests.... Entre la théorie et la pratique....

Donc, je te suis avec intérêt !!

Courage.

Fred.