benoar a écrit 4244 commentaires

Pour ceux que cela intéresse, je me suis aussi renseigné pour un boîtier externe USB3 dont le chipset gère lui-même la mise en veille (ASMEdia ASM1051 par exemple). Et ben là aussi c'est le far west et je n'ai pas réussi à trouver.

À noter pour les disques USB : certains permettent de passer des commandes directement au disque avec sdparm (plutôt que hdparm). Et depuis l'USB3, il y a normalement l'“USB Attached SCSI” qui permet également cela, dans le standard et donc normalement utilisable partout. Par contre, je ne sais pas ce qu'il en est du support soft.

Mais justement c'est une vrai debian dès le début. Avec une couche proprio au dessus pour avoir une belle interface web, mais c'est tout.

OK. Mais le support de cette plateforme est-il intégré upstream chez Debian ? C'est plutôt de ça dont je parlais. Car les installations de Debian « ad-hoc » pour les NAS, il y en a plein (voire de simples chroot…). Mais dans la durée, ça ne tient pas, car il n'y a aucun support des versions suivantes.

Il y a potentiellement quelques drivers pas libres tout au plus, j'ai pas été vérifier ça.

Ah, on arrive encore aux merdes classiques… mauvais point pour Synology, qui m'a plutôt impressionné avec ton histoire, quand même.

L'intérêt principal pour moi pour cette machine c'était son prix: à 100€ il est difficile faire quelque chose d'équivalent, qui est toujours utilisable par Madame Michu, et bidouillable par ssh. Certains NAS sont moins cher mais complètement fermés, d'autres sont plus ouverts (Synology, firmware libre) mais plus cher. C'était un bon compromis pour moi.

Oui, je comprends que le rapport utilité/prix est vraiment pas mal. Moi je table sur l'occasion pour avoir des prix corrects ;-)

Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…

Ça me rappelle un disque que j'avais sur un laptop, qui est mort d'un trop grand nombre de (dé)chargements de tête. Ça serait pas un Hitashi ? J'avoue ne pas comprendre comment on peut arriver à mettre une si petite période, mais bon… mystère.

Si tu fais du bittorrent à longueur de journée, cela n'a même plus de sens de chercher à parquer les têtes (puisqu'il va probablement y avoir une demande d'accès dans les 5 mn).

A l'inverse, si tu as bien réglé ton délai avant parquage à une valeur raisonnable de 5 mn, cela ne servira à rien si tu as un process parasite qui accède au disque toutes les 3 mn.

Je ne comprends pas : dans les deux cas, tu as une période d'utilisation inférieure à la période de parquage, et donc les têtes ne se parquent jamais. On aurait un accès toute les demi-heure, avec un parquage de 5 min, ça ferait un nombre de chargements raisonnables. Bref, pas besoin de faire « en fonction » de l'utilisation, une valeur genre 5 minutes irait très bien pour une machine fixe. Le mettre à 30s sur un laptop, pourquoi pas, même si je ne suis pas convaincu de l'effectivité de la résistance aux chocs…

Ce n'est pas si compliqué que cela (enfin c'est relatif je te l'accorde). Si cela t'intéresse tu peux faire une demande sur le forum et j'y répondrai.

Merci, c'est sympa, mais je n'ai pas trop le temps de faire ça pour l'instant. Une autre fois, peut-être.

Merci pour le lien, très intéressant. J'ai déjà vu des points de connexions sur des SSD qui ressemblent trop à un port série ou à un JTAG… je me suis toujours dit qu'il fallait que j'essaye un jour. Mais bon, pas le temps…

195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 12350589

Avec ce genre de valeur qui ne veut rien dire, effectivement, c'est un disque nase qui ne file pas beaucoup d'info intéressante.

Oui enfin le mieux c'est quand même de choisir un NAS qui supporte une vrai Debian dès le début ! Voir par exemple la page de Martin Michlmayr http://www.cyrius.com/debian/

Du coup, ça démystifie beaucoup le truc et ça devient « normal » d'avoir un ordi comme un autre avec une Debian, sur lequel tu peux installer toute la logithèque Debian, même si c'est un armel et qu'il consomme 5W…

smartctl a confirmé mes craintes : il est monté à 56°C !

Bah si t'es effrayé par ça…

194 Temperature_Celsius     0x0022   052   031   000    Old_age   Always       -       62 (Min/Max 12/69)

et son copain à peine moins. Ce sont des Samsung, mais le NAS est placé dans un environnement plutôt fermé.

Rhaa, mais faites du awk correct bon dieu !

sudo smartctl -a $(awk '$2 == "/" && $1 != rootfs { print $1 }' < /proc/mounts) | awk '$2 == "Power_On_Hours" { poh = int($10) } $2 == "Power_Cycle_Count" { pcc = int($10) } END { print poh / pcc }'

mais pas de N Load_Cycle_Count est-ce normal et dans ce cas pourquoi ?

Les données SMART sont assez mal standardisées, et on n'a pas toujours tout. Tu as peut-être d'autres valeurs se rapprochant de cette signification ?

Si je calcule Power_On_Hours/Power_Cycle_Count j'obtiens environ 6.6, puis-je en déduire (en considérant que ma machine utilise tout le temps ce disque) que ma machine est allumée pendant 6 heures et 36 minutes en moyenne ?

Oui, si ton disque est allumé tout le temps quand ta machine l'est.

Le Red a un LCC de… 2.

Au début, j'ai pensé à une valeur erronée, mais en fait c'est peut-être bien vrai. Je viens de voir qu'en fait, le LCC de mon autre NAS n'a pas bougé depuis 48h ; avec les bons réglages, ça marche bien. Mais comme je disais, c'est plutôt les réglages inconscients d'origine qui m'horripilent.

J'imagine que cela dépend de sa sollicitation selon l'agencement du RAID.

Peut-être. Ça voudrait dire que celui à 200 000 est vraiment peu sollicité (paradoxalement), et que ses réglages sont pourris : mieux vaut corriger ça avant qu'il merde vraiment.

Je pense que c'est plutôt une valeur erronée, ça me paraît complètement impossible. Il y a beaucoup de valeurs SMART qui ne veulent rien dur car niveau standardisation, c'est un peu la misère.

Les constructeurs se mettent au 2,5" plus pour la conso d'énergie et la densité (oui, la densité au sens volumique du terme : on fait tenir plus avec des 2,5" que des 3,5" dans un serveur, i.e. il existe des 2To en 2,5" pour 4To en 3,5", alors que la différence de taille (physique) est énorme). Car question fiabilité, les 2,5" qu'ils utilisent ne sont pas ceux du commerce, à part pour les grosses fermes de données où on s'en fout que ça soit fiable à 3,5 ou 2,5" ; c'est des SAS 10k ou 15k, nettement plus endurant. Et aussi, ça permet de rentrer des SSD, qui sont encore plus prisés quand on veut vraiment des perfs.

Ici, sur ce NAS, j'ai dans /etc/default/hdparm :

hdparm_opts="-B254 -S36"

Mais le coeur du problème, c'est trouver ton process qui réveille ton disque. C'est en général pas trop dur à trouver (il faut juste logger tous les accès disques et tu trouveras rapidement le coupable).

Franchement, non, ça n'est pas ça le problème : c'est normal que l'OS veuille écrire des trucs de temps en temps. Par exemple, il sert également de client bittorrent (chose proposée également sur le firmware d'origine, donc il n'y a pas de raison que ça soit « hors spec »). Le truc, c'est que le disque n'a pas à parquer ses têtes toutes les 30s quand c'est du matos fait pour ne pas bouger.

Quant à la « facilité » de trouver les accès disques, j'avais déjà essayé à une époque, ça n'est pas si simple que ça, ou alors je veux bien une doc :-)

Sur un grand nombre de SSD, l'activation du trim (-o discard) entraîne une perte de perf. considérable.

Franchement, se baser sur l'avis d'un mec qui a mis ça dans le wiki… Sans sources, ça me semble exagéré de dire ça. Et ça omet complètement les problèmes d'usure que ça entraîne de ne pas le faire.

Les FS modernes n'ont carrément plus besoin du trim.

WTF ? Soit je n'ai pas compris ce que tu dis, soit tu n'as pas compris le fonctionnement du trim… Bien sûr qu'il sera toujours très utile, et pas que pour les SSD (en virtualisation c'est pratique pour avoir des volumes sparse).

Le trim (Appelé discard sous linux) est trop problématique à plein de niveau.

Les soit-disant « problèmes » évoqués sont juste que discard fait effectivement très bien son boulot : il dit au SSD qu'il peut supprimer ce bloc, et donc oui, forcément, si tu veux le récupérer après un "rm" mal placé, bah tu peux pas, et oui si tu veux être discret sur les zones effacées ou non de ton disque pour des raisons de confidentialité (disque entièrement chiffré), il ne faut pas l'utiliser. Mais désolé, ce sont deux cas d'utilisation très spécifiques et le discard marche très bien pour tout le monde dans 99,9% des cas.

Là où le discard est intéressant, c'est pour la durée de vie du SSD et les perfomances : ça les améliore, car il a moins besoin de refaire de la réécriture interne pour trouver de la place. Perso, je pense que les chiffres classiques d'amplification d'écriture sont souvent beaucoup sous-estimés car ils ne prennent pas en compte une charge classique mais très mauvaise pour les SSD : plein de petites écritures aléatoires. Après, un FS peut mitiger le problème en essayent d'être « gentil » avec le disque à ce niveau, cf par exemple l'option "ssd" (voire ssd_spread pour les contrôleurs vraiment merdiques, i.e. les cartes CF/SD / clé USB, mais faut être un peu maso) de btrfs.

À priori, ce comportement vient d'une « mauvaise utilisation » historique. Avec un terminal comme uRxvt, on peut avoir du vert clair ou foncé gras, avec l'option "+is" (intensityStyles) qui respecte les couleurs théoriques (i.e. on a bien un vert foncé gras avec "\e[1;32mYO" et un vert clair gras avec "\e[1;92mYO").

Ce qui veut dire qu'il faut toujours bien un modem 3G en plus mais il est effectivement intégré au hardware (mais certainement pas au CPU) de manière à pouvoir communiquer avec le CPU quand le système est « éteint ». Ce qui se ferait typiquement sur un laptop.

Si on regarde la datasheet du modem donnée en exemple http://archive.ericsson.net/service/internet/picov/get?DocNo=35/28701-FGB101576&.. il est relié en USB par le port mPCIe. Donc il doit être alimenté pendant que la machine est éteinte, chose « classique » sur des bécanes quand on configure un tout petit peu le BIOS (pour allumer la machine au clavier, par exemple), et doit pouvoir facilement déclencher un allumage par interruption. Bref, c'est juste une intégration ingénieuse de matos on ne peut plus classique.

Bon, dans ce que je comprend du papier d'Intel, le modem 3G c'est quand même un device à part donc je vois pas trop d'où Jim Stone sort que c'est intégré à la puce mais j'ai peut-être raté une référence.

Dans le lien que tu mets (merci au passage), il est clairement indiqué que le lien 3G est effectué par une passerelle externe, reliée en Ethernet à la machine, et que l'AMT passe par celui-ci.

Quand on voit le ton du texte et les images du site d'origine, ça fait clairement conspirationiste à deux francs.

Mais putain arrête de pourrir ce site avec tes réponses vides d'argument, insultantes et basées sur tes pauvres expériences persos. Tu ne réponds même pas aux commentaires intéressants de groumly et René (ou alors tu choisis les parties qui t'arrangent). Moi je n'ai pas envie de te donner que des baffes.

Pour éviter ça, tu peux utiliser les raccourcis clavier, ça va plus vite et ça ne nique pas ta sélection : Ctrl+K puis Backspace puis Clic milieu.

Wahou, on dirait que tu as été traumatisé par des végétariens quand tu étais petit…

Sur le fond, je suis parfaitement d'accord pour dire qu'on mange trop de viande : les apports nutritionnels ne justifient pas de manger de la viande à tous les repas ; les quantités servies sont souvent excessives, et il vaut probablement ne pas manger de la viande de mauvaise qualité.

Et donc, comment fais-tu pour ne pas manger trop de viande, pas à tous les repas, pas en quantité excessive, et de bonne qualité, quand dans 99% des situations hors de chez toi (cantine, restaurant, amis) tu vas justement te retrouver face à de la viande industrielles pas chère dégueulasse en quantité ? Et toi tu nous parles des 1% des cas où il y a du végétarien disponible, pas cher, des abats, ou de la viande « non polluante » ? Bah tu refuses poliment. Et parfois tu expliques aux gens que quand tu te retrouves dans cette situation 99% du temps, oui, ça te donne envie de les informer.

Mais tout ceci ne peut pas justifier une position dogmatique, qui peut aller jusqu'à se montrer impoli, voire outrancier, en société, à raconter n'importe quoi pour se justifier, et à émettre un jugement moralisateur sur les gens qui se comportent de manière logique.

Je ne sais pas qui tu as rencontré, mais d'un côté, vu comme tu te places comme « logique », je pense que j'aurais du mal à ne pas être outrancier/moralisateur en face de toi…

Ce genre de timeout, ça ressemble à quelque chose lié au réseau. Pourrais-tu tu faire un tcpdump voir si tu vois quelque chose ?

Je parle tcpdump avant le « reste » car je ne vois pas trop comment tu aurais pu faire des changements de config qui arrivent à ça, vu que normalement su n'y touche pas trop (autant sudo fait de la résolution de nom, mais pas su, je crois), mais aussi car vu comme c'est louche, ça pourrait être dû à quelque chose que tu ne contrôle pas (rootkit ?…).

Tu as trouvé un bon tutoriel, ou tu penses faire de l'ingénieurie (sic?) inverse et coder des pilotes ?

Je n'ai pas de tutoriel tout cuit, mais j'ai déjà fait du portage pas trop bas niveau vers Debian ou autre, pour des archis « exotiques ».

J'avais vu ça moi aussi. Mais ça suppose néanmoins de trouver un moyen efficace de gérer tout ce qui touche au défilement de l'écran, y compris celui de la ligne de commande.

Alors le défilement, c'est autre chose : justement, je pense qu'il ne faut pas faire comme ça avec ce style d'écran, mais plutôt partir sur un truc genre écran circulaire… Oui, bon, encore quelque chose qui ne va pas faciliter le portage.

Bref, c'est un superbe projet, mais ce n'est pas gagné…

Clair. Pour moi, ça a une chance non négligeable de tomber à l'eau, mais je j'ai toujours ce projet sous le coude au cas où. Le jour où un truc style laptop sort avec un écran e-ink, je saute dessus.