Fravadona

Donc pour le moment tu n'as rien d'autre que le partage Windows d'actif sur le NAS ? Pas de service d'indexation, CloudStation, PhotoStation, VideoStation, etc ?

Si ton CPU est a 100% lors de la copie alors a priori c'est lui qui n'est pas a la hauteur. Peut-etre qu'en utilisant SMB1 (a priori moins gourmant que SMB2) ca ira mieux. PS: les jumbo frames doivent etre configurees au niveau du switch et de chaque appareil connecte, sinon ca ne fonctionne pas du tout comme on voudrait : + de charge CPU et - de debit au lieu de - de charge CPU et + de debit Tu as un volume basique par disque ?

Le "avant" etait avec le meme appareil, sur le meme reseau wifi exterieur, et les memes fichiers audio ?

RAID0 et JBOD sont les seules configurations qui font ce que tu voudrais, mais non seulement elles sont très risquées mais en plus il est impossible d'y "remplacer" un disque.

Cette configuration n'est pas authorisée par Synology (va savoir pourquoi). Par contre quelqu'un sur le fofo s'y ait attaqué et a semble-t-il réussi a le mettre en place mais la méthode est plutot technique.

Malheusement oui. Tu peux peut-etre contacter Syno, ils pourraient avoir une solution comme te fournir un kernel Linux specialement pour pouvoir faire ca

Pour ce qui est de e2fsprogs le Syno (DSM 4.3) semble posseder la bonne version, mais vu que ca bloque tout de meme pour cause de GDT non alloués cela veut dire que c'est le kernel (3.2) du Syno qui est fautif. La seule solution pour toi serait de casser ton volume puis de le recreer directement avec tous les disques.

Tu as peut-etre une limitation de 16To, verifies la fiche technique de ton NAS. Ce qui te bloque toi est : kernel: [ 295.826690] EXT4-fs warning (device dm-0): ext4_resize_fs:1997: No reserved GDT blocks, can't resize Alors que le probleme precedent qui necessitait un fsck etait : kernel: [66650.572404] EXT4-fs warning (device dm-7): ext4_resize_begin:32: There are errors in the filesystem, so online resizing is not allowed

/var/log/messages ne parle pas de corruption dans le système de fichiers ext4 , je ne suis pas sur qu'un fsck puisse resoudre le souci Sinon pour la procedure ca m'a l'air correct, et tu ne risques "quasiment rien" avec un fsck mis a part perdre quelques fichiers qui seraient réellement corrompus.

I know I know ;-)

loicb a dit ca sur le tchat, et a priori il n'avait pas "vu"/lu ton lien

si sur le 8081 ca ne fonctionne pas alors pourquoi utiliser celui-la ? Comment fais-tu pour visualiser avec Firefox ?

Je suppose que tu as connecté le nouveau disque a ton PC, mais SATA ou USB ? Il faut que tu fasse une ecriture de zero sur tout le disque puis un test smart etendu (tout avec datalifeguard) Ps: ne pas te planter de disque

Quand tu dis "detecter", tu ne rentres pas l'ip de la cam dans SS ? Dans firefox ti tapes http://ipcam:8081 ?

Ah! c'est mon intervention que tu as mal pris ? Désolé, CoolRaoul t'avais deja répondu et je réagissais a l'article, mais c'était un peu hors sujet par rapport a ta demande. @CoolRaoul: Merci d'avoir expliqué le quiproquo

Je ne comprends pas en quoi le fait de prendre le controle du registar aiderait a combatre un virus, c'est n'importe quoi !!!

ce disque "neuf" ne va pas faire long feu ...

DataLifeGuard : http://support.wdc.com/product/download.asp?groupid=609&sid=3&lang=fr

le WD Caviar RED (Ref. WD20EFRX ) dispose de 2,000,398 MB avec des secteurs de 512, c'est ok pour remplacer le tien

Pour repondre a ta question principale je te conseille de rester sur du WD, tous leurs disques ont l'air de faire la meme taille, et au pire eux au moins specifient la taille exacte donc c'est simplea verifier

Ca c'est plutot un probleme de nomenclature , les OS utilisent des unites multiples de 1024 alors que les fabriquants utilisent des multiples de 1000

D'apres le datasheet ton WD 20EARS fait exactement 2,000,398 Mo. J'essaie de trouver la valeur exacte pour des 2To de chez Hitachi ou Seagate mais ces constructeurs ne sont pas clairs, ils laissent penser que leurs disques font 2,000,000Mo, ce qui serait trop petit pour toi.

Si tu n'as pas tronqué ton volume (par exemple a un multiple de 10Go) alors faut que ton nouveau disque possede au moins le meme nombre de secteurs que l'ancien. Apres, il est toujours deconseille de mixer les modeles de disque dans une baie mais vu qu'un nas syno n'a une grande densité de disques ce n'est pas trop grave

Les fichiers ont bien été copiés sur le NAS, le problème vient du find qui ne les trouve pas quand on utilise un é comme motif de recherche (mais ca fonctionne avec un e) FravadoNAS> find . -name '*e*' mémé_osx.txt mémé_win.txt FravadoNAS> find . -name '*é*' mémé_lin.txt

Vu que l'assignation de numero de volume est arbitraire, elle se doit d'etre inscrite quelque part sur les disques. Il faut savoir que sur les volumes SHR il y a une petite partition de 12Mo en debut de LVM qui est "réservée au système", et cela pourrait être la cause du soucis. A vue de nez je dirais que ton ancien disque 4 (dans le slot 2) et ton nouveau disque 4 (dans le slot 4) sont tous les deux montes en meme temps dans /volume4 ; du coup seul un des deux est accessible. pour verifier : mount | grep "/volume"