gaetan.cambier

ca serait deja + simple d'utiliser le client ldap sur le syno

ce qui est bizarre, c'est qu'il nome intel comme cpu dans la news ici : http://www.nextinpact.com/news/93506-synology-nas-ds215-ds715-ds1515-et-routeur-wi-fi-802-11ac-avec-interface-maison.htm mais affectivement, j'avait lu anapurma autre part, question bete: docker, qui est l'appli de virtualisation de dsm 5.2 semble etre uniquement compatible cpu intel. si tous les nouveau modele sont equipé de cpu arm meme en haut de gamme, c'est pas très logique j'ai du raté quelque chose

vois pas l'interet d'ajouter un paquet pour les zip vu que pour la decompression, ils sont pris en charge direct par dsm ...

http://www.nextinpact.com/news/93506-synology-nas-ds215-ds715-ds1515-et-routeur-wi-fi-802-11ac-avec-interface-maison.htm seul le ds1515 est reellement nouveau, les autres sont des evolution de modele connu le ds1515 serait bien pour ceux qui ont besoin de place à moindre frais par rapport au ds1515+ les fichiers technique ne sont pas encore dispo, j'aurai aimer savoir si on pouvait ajouter de la ram au ds1515 bonne lecture

en effet, c'est en double, faudrait plutot voir avec synology le pourquoi exact de ce doublon, si il y a une vrai raison dans le doute, rempli les champ en double, c'est ce quej'ai fait sans meme me rendre compte que l'info etait en double :s

ne pas stocker en fichier compresser des document que l'on a besoin

non, le shr est un raid avec une couche lvm, rien qui impacte sur les performance

plutot un seul compte par session, si il y a plusieur session sur le pc, on peux utiliser plusieurs comptes

en ssh, que renvoit cette commande : ls -la /var/services/tmp/

faut pas oublier aussi que le jbod est plutot utilisé en raid multiple, lorque en dessous, on a par example plusieurs grappes raid5/6 que l'on veux assemblé comme le fait le lvm maintenant et que synology utilise dans sa solution shr.

oui, c'est du grand n'importe quoi : et c'est pourtant simple à comprendre, le jbod met les disque cote à cote pour formé un volume ca veux dire que un fichier stocké peux etre sur le disque 1, sur le disque 2, ou bien à la fois sur les 2 (la fragmentation existe meme sur ext4) egalement, ext4 comme pour tout système de fichier, tu as quelque part sur le disque un index des fichiers/dossier --> si tu perd cet index bonne chance pour retrouver tes données (sauf société spécialisé) bref, c'est pas + sur qu'un raid0, c'est juste + facile à récupérer pour les société spécialisé vu que presque 50% des fichier seront récupérable à prix d'or dans tous les cas, meme avec du raid, faut pas oublier une bonne sauvegarde

les test sont fait avec un pc fixe ou portable ? moi, j'ai un portable, et selon que l'economie d'energie soit mise ou pas, les debit passe du simple au double :s faut se méfier de tout pour les test

non, avant le resize, fallais changer la taille du raid avec le --grow

l'eternelle question qui revient

non, jbod raid0, meme combat, tu perd un disque tu perd tout le raid5/shr ou volume basic son + sur par contre, si il y a deja 6 to de donnée, vaut mieux voir grand pour les disque, pour pas les changer trop vite

perso, j'ai le : Onduleur APC BACK UPS BE550G-FR - 550VA c'est 0db bon, un onduleur line interractive, c'est mieux, on peu pas dire le contraire vu qu'il staboilise la tension, et l'onduleur offline ne fait que passer sur paterie lorsque l'on sort de la plage acceptable mais bon, le principal, c'est de ne pas avoir de coupure pour le nas, ce que rempli parfaitement un onduleur offline et puis 50db, perso, comme j'ai pas une salle dedié pour mettre ce matieriel, je supporterai pas cote consommation, on onduleur consomme toujours, et si je me trompe pas, le line interractive consomme plus à cause de fait qu'il redresse le courant en permanence, mais combien exactement, je ne sais pas

risque de tout perdre, le risque est qd meme faible, meme si c'est une beta, toute la partie filesystem (ext4) raid (mdadm) lvm utilisée sont connu et bien stable maintenant, des bug sur la beta, parfois très genants, pourrait arrivé, ca s'est sur.

ajouter un repertoire à indexation du serveur multimédia reglera le problème

Non, c'est le site officiel, tu as télécharger quel fichier ?

mais si le tu est à 9000 sur le nas et à 1500 sur le switch, le switch va fragmenter les paquets, ce qui peux tout ralentir, si il ne tient pas la cadence

http://ukdl.synology.com/download/DSM/5.0/4528/

bon, donc j'ai pas merdé qd j'ai fait mes calcul c'est le dsm qui pour une raison inconnue, n'alloue pas tout l'espace en créant le raid, c'est bizarre, mais c'est pas un problème disque en tout cas, si cela peux te rassurer c'est un mystère de synology sur leur systeme de creation de partition ou alors, ils ont changé leur script de creation de partition à un moment, ce qui fait que tu as des resultat different sur ton autre nas

oui, renommer le dossier original en ssh, recréer le dossier via l'interface graphique et déplacement des données en ssh çà reste le + sûr

c'était mon message de réveil çà 160 blocs = 160ko (ca limite le problème ) moi, j'ai arrondi le nombre de block à un multiple de 16, comme dsm fait il me semble --> sur le disque ou on a travaillé, on a perdu en fait 1 secteur (512 octect) 160ko, c'est peu, et c'est beaucoup, tu est sur que c'est les meme disque phisiquement ? bon, quelque commande pour comprendre ce qu'il se passe : sfdisk -l /dev/sda sfdisk -l /dev/sdb pour deja pour si les partition sont les meme et après, on verra, mais je pense que ca pourrait venir des partitions moi, je t'ai fait agrandir la partition de ton disque au max p-e que par securité, dsm laisse une marge, faut voir

Pas de gros risque d'incompatibilité entre switch et injecteur du côté non alimenté, c'est une simple connections rj45. Tant que tout le matériel est a peu près récent. Faut pas non plus choisir un équipement préhistoriques [emoji14]