Jump to content
XPEnology Community

nicoueron

Moderators
  • Posts

    1,920
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by nicoueron

  1. J'ai pris en compte tes remarques, merci pour ta contribution. Le temps passe depuis la création de ce topic pour notre N54L. Depuis les dernièers releases du loader Redpill, les options d'installation de DSM sont les mêmes que pour une installation classique. Donc à part un gros bouleversement du loader et/ou une grosse coquille dans les captures d'écran du BIOS, le tuto ne sera plus mis à jour.
  2. As-tu le même pb lorsque tu copies un fichier de ton PC vers le NAS ? Moi il est vrai que je rencontre quasiment le même souci sur downloadStation mais seulement sur les téléchargement HTTP/S (ce que tu appelles Direct DL je suppose) pas en BT :
  3. Je ne suis pas sur d'avoir compris. l'inode est différent c'est sur. Je pense qu'ici c'est comme tu l'indiquais : ils ne sont pas sur la même partition. Tant pis ça restera comme ça!
  4. Pas possible hélas : root@NAS:/var/packages/DownloadStation/target/bin# ln -i /usr/bin/lftp lftp ln: failed to create hard link 'lftp' => '/usr/bin/lftp': Invalid cross-device link En tout cas merci pour ces pistes @JacquesF
  5. Bon mon idée en tout cas génère en boucle de nouveau processus lftp! soit une belle boucle infinie...
  6. autre idée : remplacer le binaire /var/packages/DownloadStation/target/bin/lftp par un lien symbolique qui pointe vers l'autre binaire lftp natif qui lui s'appuie sur le fichier de conf...
  7. J'avais déjà essayé de regarder si il y avait des fichiers de conf qui serait utiliser par lftp mais hélas aucun fichier autre que le binaire lftp ne contient ces paramètres... J'ai l'impression que c'est un binaire spécifique dédié à DownloadStation pré-compilé avec ces instructions et du coup ce n'est pas modifiable - dommage
  8. Voici la ligne de commande qui est lancée lors d'un téléchargement https : root@NAS:~# ps -ef | grep lftp Downloa+ 14286 1 72 10:35 ? 00:00:17 /var/packages/DownloadStation/target/bin/lftp --norc -c set ssl:verify-certificate false;set syn o:task-id 1158;set syno:username niko44;set net:timeout 30;set net:max-retries 3;set http:user-agent "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/5 35 (KHTML, like Gecko) Chrome/14 Safari/535";set xfer:log false;pget -c -n 4 -O /volume1/@download/1158 "https://www79.uptobox.com/dl/BLABLABLA.iso"; J'ai l'impression que DownloadStation utilise sa propre configuration de lftp sans tenir compte du fichier /etc/lftp.conf car l'option ssl:verify-certificate false n'est pas dans le fichier de config alors que ce n'est pas la valeur par défaut. De même je ne vois pas d'autre fichier de config associé dans lequel je pourrai mettre ton flag.
  9. Très bonne piste mais hélas sans succès. Juste pour préciser mon test : j’ai modifié le fichier /etc/lftp.conf puis redémarrer le service DownloadStation et relancer un nouveau téléchargement mais toujours pareil.
  10. oui tu peux rebasculer sur tinyOS et relancer le build du loader après avoir modifié les paramètres. D'ailleurs depuis qq mise à jour du loader, il semble que cette config détectée soit correcte, du moins chez moi maintenant elle marche
  11. Non comme je l'ai indiqué ce n'est pas le serveur distant qui pose pb. Le download du même fichier (ou d'autres peut importe) depuis un autre client (mon pc perso par exemple) plafonne bien à 100Mo/s. C'est clairement le processus qui sature le CPU. Mais la raison est j'en suis quasiment sur est le checksum des paquets qui pour une raison qui m'échappe nécessite une correction des trames qui utilise toute la CPU et donc bloque le débit. J'ai eu un moment le même pb avec les transfert SMB (consommation CPU à 100%M et débit plafonné entre 10 et 15Mo/s) et cela venait du cable réseau RJ45 entre mon switch et le NAS qui était de mauvaise qualité semble-t-il. Pour être plus précis il avait un connecteur metallique qui devait avoir un tout petit défaut et je l'ai remplacé par un autre cable avec un connecteur en plastique et depuis RAS. Mais là pour lftp je ne pense pas que ce soit le cable mais plutot un pb de MTU ou qqchose du genre.
  12. merci pour cet exercice. J'arrive de temps en temps à faire des pointe à 30-35Mo/s également. C'est donc bien une limitation de performance du N54L dans le cadre d'un download http. Le truc, c'est que si il consomme autant c'est qu'il corrige des erreurs de transmissions, je ne vois pas d'autres explications. Je suis sur que si nous avions un CPU plus performant nous nous en rendrions pas compte. Donc à ce jour ma seule piste reste donc le MTU. A tester au risque de planter l'interface réseau du NAS^^
  13. Bonjour à tous, Je poste ici un pb que je constate depuis que j'ai la fibre - je ne m'en étais jamais rendu compte auparavant car je n'avais pas d'abonnement chez Uptobox et encore moins quand j'avais l'adsl évidement. Bref, lorsque je télécharge un fichier depuis Uptobox, le téléchargement est bridé à 25Mo/s. Pour certains vous allez me dire que bon c'est pas si mal, mais normalement je devrais être aux alentours de 100Mo/s (comme sur mon PC par exemple). C'est un constat que je fais exclusivement avec DownloadStation et les téléchargements en http, je n'ai pas le pb avec les torrent, le débit est bien à 100Mo/s. En regardant de plus près les processus, mon NAS surconsomme la CPU pour le téléchargement en cours et notamment le service lftp de DownloadStation qui monopolise tout. Je suspecte un pb de trame http qui nécessite une vérification de chaque paquet. J'aurai envie de jouer avec le MTU (dont la valeur par défaut est 1500) du NAS mais j'ai peur de faire une bêtise. Avez-vous une idée ? Pour info, le NAS est relié directement à ma Freebox Delta en gigabit avec un cable cat 7 et je me répête aucun pb avec des torrent, c'est exclusivement avec un download http (ou https).
  14. Salut, Es-tu sur que l'ensemble de tes 6 disques correspond bien à ce que tu as ? Peux-tu vérifier si suite à la coupure de courant, la configuration de ton BIOS n'a pas sautée (CE1 disabled, config SATA en AHCI, etc.) ? et que la pile du BIOS est toujours bonne ? supprimer le volume et le recréer est une TRES mauvaise idée^^ il vaut peut-être mieux tenter une réinstallation de DSM qui pourra (sans conviction) le réparer. En dernier recours, passer par une autre distribution linux et remonter la grappe RAID de façon logicielle pour relire tes qq To qu'il te manque.
  15. Ouch 30Go sans paramétrage effectivement ça fait bcp! Et si justement tu mettais le nez dans les paramètres pour tacher de comprendre pourquoi il prend autant de place ?
  16. Salut, Tu peux relancer la commande dans chaque sous dossier de /volume1 pour être encore plus fin sur quel dossier grossi sur ce point de montage : sudo du -h -d 1 /volume1/@appstore et ainsi de suite. Il est possible que ce soit les logs d'un package ou alors le téléchargement d'une dépendance
  17. Je ne sais plus exactement mais de mémoire un simple : ./rploader.sh update repull depuis le repo github la dernière version. Ensuite il suffit de relancer les commandes habituelles.
  18. Ah, dommage mais pour ton cas tes disques de 10To (ref ST10000NE0008 - 2PL103) ne font pas parti de la liste des disques supportés : ST10000VN0008 - 2JJ101 ST10000VN0004 - 2GS11L ST10000VN0004 - 1ZD101
  19. Ahh effectivement je n'avais pas vu cette option à partir du gestionnaire de disques. Mais chez moi aussi c'est grisé malgré 2 IronWolf sur 4 de mes disques. Je pense que la raison est qu'il faut des disques de 4To minimum dixit : Quels disques Seagate prennent en charge Seagate IronWolf Health Management sur DSM? - Synology Centre de connaissances
  20. je ne vois pas ça chez moi dans les tâches planifiées, juste un test SMART classique exécutés 1x par mois. Moi ce que j'ai constaté, c'est que le logo Ironwolf n'est plus affiché dans le gestionnaire de disques depuis DSM7.
  21. J'ai constaté cela également depuis DSM 7. Je pense que c'est une volonté de Synology d'avoir enlevé cette option, non?
  22. La ou les question(s) dans ce fil de discussion ont reçues une réponse et/ou l'auteur à résolu son problème. Ce fil de discussion est maintenant fermé. Si vous avez d'autres questions, merci d'ouvrir un nouveau fil de discussion.
  23. c'est normal, Pocopico a volontairement changé l'url d'appel à Synology lors du build du loader.
  24. tu veux dire en désactivant cette option
  25. Pourtant sur les séries HP N54L comme moi c'est obligatoire sinon les disques ne sont pas reconnus justement.
×
×
  • Create New...