ganjo

je pense qu'il ne sera jamais possible d'utiliser arlo avec surveillance station, les arlos n'étant pas faites pour filmer h24 (autonomie oblige)

En l'occurence tout c'est bien passé

En fait j'ai trouvé la solution (apparement quelqu'un d'autre avait déjà eu un problème semblable): http://forum.synology.com/enu/viewtopic.php?f=39&t=61747 je suis assez étonné, il semble que dsm ne démonte pas correctement le volume. Je doute que cela soit un bug de dsm lui même, vu que j'aurai à ce moment là trouver bien plus d'info sur le net. J'ai bien installé optware et un module fuse "homemade", mais j'avais désactivé les 2 et je ne vois pas en quoi ça gène. Enfin bon, le passage vers du raid5 est en train de ce faire, je vous dirai si tout c'est bien passé Merci pour votre aide

Possible ceci dit en fouinant dans les log c'était déjà la situation lorsque j'avais mon volume à 3 disques en raid1... et dsm semble avoir repercuter le passage à 2 disque sans problème

Merci de tes réponses (et du temps que tu as du prendre pour faire tout ces essais) En fait l'option apparaissait bien, mais n'a jamais fonctionné chez moi Je viens de corriger ce problème, mais en fait ça ne fonctionne toujours pas, lorsque je tente de faire la migration j'ai l'erreur suivante dans les logs: Feb 24 15:16:02 poolhandler.cgi: lvm_vg_deactivate.c:25 Failed to do '/sbin/vgchange -an /dev/vg1 > /dev/null 2>&1' Feb 24 15:16:02 poolhandler.cgi: space_migrate_raid1_to_5.c:89 Failed to deactivate /dev/vg1 Feb 24 15:16:20 kernel: [ 817.730000] nfsd: last server has exited, flushing export cache Feb 24 15:16:21 kernel: [ 817.750000] svc: failed to register lockdv1 RPC service (errno 97). Feb 24 15:16:21 kernel: [ 817.760000] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory Feb 24 15:16:24 poolhandler.cgi: space_migrate.c:405 Failed to migrate '/dev/md2' from RAID 1 to RAID 5 Feb 24 15:16:24 poolhandler.cgi: space_lib.cpp:422 Failed to migrate space '/dev/vg1', migrateType: '8' Feb 24 15:16:24 poolhandler.cgi: poolhandler.cpp:565 failed to migrate space: /dev/vg1 et /sbin/vgchange -an /dev/vg1 Can't deactivate volume group "vg1" with 1 open logical volume(s) Oui excuse j'aurai du être plus précis en fait la migration de raid1 vers 5+spare n'a jamais marché chez moi, j'avais mis (à tort) cela sur le fait qu'il avait besoin de créer dabord les 2 disques de spare. DSM ne me permetait plus de faire grand chose, et je pensai qu'il me fallait absolument revenir a un raid1 à 2 disque (ce que dsm ne permet pas), j'y suis donc aller à l'huile de coude... mais sans réel succès quant à mon problème principal

Je me réponds Pour reduire le nombre de disque dans du raid1, il faut supprimer les disques (je l'ai fait physiquement, mais ça doit marcher avec mdadm --remove), puis simplement, via la cli, taper mdadm --grow -n2 /dev/md2

Bonjour j'ai un ds411 avec 3 disques en raid 1 j'ai racheté un disque en pessant passer en raid5+spare, néanmoins sur le syno cette opération semble impossible (erreur: "System failed to add spare disk") en cherchant dans la doc de mdadm, il semble en effet que le passage ne se fasse que de 2 hd en raid 1 vers du raid5). J'ai du coup essayé de retirer un disque, mais à ce moment ma grappe est considérée comme dégradée et je ne peux que la réparer. (et en faisant une connerie je me suis retrouvé avec une grappe de 4 disques en raid1...) Bref, d'où ma question: lorsqu'un volume est en raid1 dégradé, peut on forcer le système à le considérer comme propre (même en passant par mdadm en cli), ou éxiste t'il un moyen de migrer d'une grappe de 4 disques en raid 1 vers du raid5+spare ?

Pour gcc ? de tête c'est optware-devel qui est un meta package qui regroupe une bonne partie des outils de dev (gcc, auto*, etc...) pour fuse les sources sont sur http://fuse.sourceforge.net/ il faut par contre reprendre la libthread fournie d'origine avec le syno: mv /opt/arm-none-linux-gnueabi/lib/libpthread-2.5.so /opt/arm-none-linux-gnueabi/lib/libpthread-2.5.so.old cp /lib/libpthread.so.0 /opt/arm-none-linux-gnueabi/lib/libpthread-2.5.so

j'ai pas tester cloudfs encore, mais j'ai compilé fuse et ruby fuse pour des besoins persos tu peux tout compiler directement sur le syno, vu qu'on y trouve des packages pour gcc

fuse compile sur mon syno et cloudfs gère swift, donc ça doit être possible je connais assez peu swift, mais je pense que n'importe quel protocole sera moin limitant que webdav ( rien que pour utiliser timemachine )

Le problème ne viendrait il pas de ton réseau ? J'ai pas de syno, mais de mon pc vers ma xbox cest relativement rapide (2-3 sec pour les grosses photos) avec un réseau gigabit, par contre lorsque j'utilisais du cpl, c'était bien plus long.