BenT Posté(e) le 10 octobre 2009 Partager Posté(e) le 10 octobre 2009 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 ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
fredlime Posté(e) le 10 octobre 2009 Partager Posté(e) le 10 octobre 2009 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
BenT Posté(e) le 11 octobre 2009 Auteur Partager Posté(e) le 11 octobre 2009 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 } #}}} Lien vers le commentaire Partager sur d’autres sites More sharing options...
BenT Posté(e) le 11 octobre 2009 Auteur Partager Posté(e) le 11 octobre 2009 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). Lien vers le commentaire Partager sur d’autres sites More sharing options...
fredlime Posté(e) le 11 octobre 2009 Partager Posté(e) le 11 octobre 2009 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. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.