Reprise du message précédent :
Pas mal. Bravo en tout cas pour ta persévérance.
Mais du coup c'est quoi ta version du noyau ?

Oui c'est pas pour rien que ma compagne dit que je suis têtu comme une mule
La version du noyau, j'en sais rien, c'est ce que donne la commande uname ? si c'est ça c'est 5.15.30-v7+ #1536

En tout cas, pas mal le support technique à donner tous ces détails.

clair.
bon, ça serait encore mieux s'ils faisaient un geste pour les cartes perdues ...

Vu qu'ils ne prennent pas en charge Linux, ceci explique certainement cela... tous les moyens sont bons pour esquiver.
Cela étant, un truc m'interpelle: ils parlent de noyau 5.1.rc1+ or on en est loin. Veulent-ils dire que c'est une modif introduite à partir de cette version? Si c'est le cas, chapeau d'être au courant d'un tel détail sur une archi qu'ils ne supportent pas.

il est aussi probable qu'ils viennent de le découvrir et vont agir pour que cela soit corrigé
il en va de leur réputation et linux est tout de même en système professionnel depuis longtemps.
le problème ne concerne peut-être que le système ARM sans impacter le linux amd64

Ils semblent être au courant de la portion de code incriminée et de la version à partir de laquelle elle a été introduite dans le noyau, ce n'est pas banal.
 
Après, les Raspi et Linux (donc Android), ça doit aussi représenter quelques cartes vendues pour eux.

J'imagine une salle immense pleine d'appareils sophistiqués et de geeks en blouse blanche qui connaissent linux sur le bout des doigts tels des Sheldon de l'informatique, du coup ça me choque pas plus que ça

Les pauvres, la référence...  

Pour info, "discard", c'est un autre nom pour le TRIM, donc la gestion de l'usure (en partie). Visiblement, les cartes aiment donc pas trop le TRIM.

Si t'as encore des cartes à bruler pour la science, tu peux tenter de rajouter l'option nodiscard dans les options de montage de ton/tes FS dans le fstab.

Ah d'accord, merci pour cette info. Je pensais que le trim était géré depuis longtemps par toutes les cartes mémoires, mais bon...
 

La science attendra j'ai reçu 8 nouvelles cartes de la part de Sandisk (juste remplacées donc), et j'ai pas trop envie de risquer de devoir encore les remplacer, mais ça aurait pu être intéressant de tester.
Mon fstab:

Ça serait quoi la syntaxe ?
/dev/mmcblk0p1 /boot vfat noatime,nodiscard,ro 0 0  ?
 
Et ça n'implique pas des trucs sur la durée de vie des SD ?

Oui c'est ça, à faire sur les 3 lignes qui adressent ton /dev/mmcblk0
 
Normalement ça améliore la durée de vie en utilisant le TRIM, mais dans le cas présent, ça l'améliorera en ne le faisant pas
 
Avant l'option n'était pas activée par défaut, donc de toutes façons j'imagine qu'en Buster tu ne l'utilises pas non plus et c'est pour ça que t'as pas le souci
 
D'ailleurs tu peux aussi tester de l'activer sur une Buster (option discard donc) pour voir (pour la science )

Ahhh voilà, ça explique tout, merci  
 
C'est quand même un peu la honte pour Sandisk et c'est incompréhensible que cette option ne soit pas gérée sur les 64go tandis qu'elle l'est sur les 32Go et tous les autres modèles...
Ça ressemble à une erreur humaine un oubli d'abaisser une manette dans la grande salle de Sheldons    
 

 
Oula non. C'est pas spécialement courant, mais c'est assez logique : une bonne partie des usages sur les cartes SD en a pas besoin réellement. Le TRIM, c'est essentiellement pour éviter les pertes en réécriture (et un peu mieux gérer l'usure), et accessoirement pour bien gérer un cache SLC. Dans les cartes SD, t'as un niveau de débit tellement bas que ça change rien, t'as pas de cache SLC, et dans pas mal de cas, t'écris des fichiers séquentiels assez gros (caméras de surveillance, APN, etc.). Le boot sur un Raspberry Pi, c'est un usage marginal en pratique.
 

 
On peut prendre les paris, mais si ça marche sur une capacité et pas une autre, y a probablement un compteur foireux dans un contrôleur ou une connerie comme ça (genre un compteur 16 bits dépassé à partir d'une certaine capacité).

Je réinstalle un Dietpi sur un RPi2v1 (ARMv7), SansDisk Extreme 16 GB. Du coup ça ne craint pas car faible capacité ?

16Go, je ne m'inquiéterais pas.

Nice
 
Bon, j'ai réinstallé Dietpi et pihole dessus (j'en pouvais plus du 1B+ qui patinait 15 min à chaque MaJ de mes adlist avec un system load > 3 pour son petit monocoeur asthmatique).
 
J'ai sélectionné unbound dessus, mais j'ai un peu de mal à saisir le fonctionnement du truc. Si je demande à résoudre forum.hardware.fr, au lieu de demander à un quelconque resolver (genre la FDN ou quad9) l'ip de HFR, ça découpe le truc en plein de petite requêtes (.fr, puis hardware.fr puis l'IP de HFR) ?
 
Si oui, a qui il demande le premier truc ?
 
 
(oui je ne suis une brèle en réseau, wifi filaire tout ça).

il va demander aux serveurs qui ont une autorité (authoritative server) sur le domaine concerné.

Unbound tu installes ton propre serveur DNS qui va savoir comment résoudre n'importe quel nom sur Internet et faire cache. Soit il a déjà l'info en cache parce qu'il l'a déjà cherchée et il te répondra avec son cache, soit quand tu tapes un nom qu'il ne connait pas, il regarde à partir des DNS racine (les seuls qu'il connait) qui fait autorité pour ce nom (qui gère le domaine) et interroges ce DNS. Au passage, il met l'info en cache.
 
Ce que proposent les DNS des providers ou ouverts, c'est un serveur de ce type qui est accessible à tout le monde (ou à leurs clients). Très bon calcul puisqu'évidemment qui fait quelle requête et quand, est précieusement conservé et exploité mais c'est une autre histoire.

Toujours autant la galère pour sourcer un zero 2w ?

Cela ne surcharge pas les serveurs DNS d'avoir plein de clients Unbound "particulier" ?

 
Nu oui mais avec en kit minimal, j'ai pas trop eu de problème avant les vacances.

 
Les DNS racines sont des éléments stratégiques d'Internet et très très solides. Leur rôle n'est en principe que de gérer les délégations (autrement dit être capable de dire quel serveur fait autorité pour quel nom), pas les détails de chaque domaine ni chaque requête qui restent sur les DNS autorité ou cache.
 
Cela étant, oui un DNS cache qui ne travaille que pour une poignée de PCs, c'est plus de boulot pour ces DNS racine parce qu'il y a peu de mise en commun. Exemple: si j'utilise un DNS Orange et que je veux consulter le site raspberrypi.org, il est probable que l'info sera déjà en cache grace à un autre utilisateur alors que chez moi, je vais provoquer cette mise en cache, m'en servir un peu et passer ailleurs. Donc chez Orange, il y aura par exemple 1 requête racine pour 100000 utilisations du cache alors que chez moi ce sera 1 pour 30 utilisations.

MMmmm 'k, merci pour les explications.
 
 
Je vais garder ce unbound et voir si ça flambe ma carte SD avec les mises en cache.

Je ne sais pas comment travaille Unbound mais je me demande si ce n'est pas un cache RAM sinon, ça doit être possible de déporter le cache sur un disque RAM.

Via dietpi il doit y avoir des optimisations pour avoir pas mal de truc en ram.

Pour maximiser la fiabilité du stockage en SSD, j'imagine qu'il faut adopter la même stratégie que les cartes SD, Plus on sur-dimensionne, plus c'est fiable en théorie..

Je me suis fait un aut-hébergement  avec un piwigo pour partage photo (des jpeg, pas de raw), un cloud Nextcloud (pas de gros fichiers ou peu), synchro contacts, visualisation de trace GPX, ... et autres modules

Je ne pense pas un jour dépasser les 150Go ! Et les SSD 250Go sont mine bien moins cher ? Cela vaut le coup de prendre un 480 Go ...

Actuellement j'ai un 480Go et il faudrait que je duplique par précaution en cas de panne (sur mon autre RPI chez mes parents)

Mais quid de la taille ? 38€ pour le 250G ou 60€ pour 480G. Si vous étiez dans la situation, vous prendriez lequel ?

Comme à gamme égale, on a autant d'écritures par cellule, plus il y a de cellules donc de capacité, plus on peut écrire d'où une durée de vie théorique plus importante.
 
Tu dis pas plus de 150Go utilisés, donc le 250 suffira donc largement.
Il faut juste voir que généralement on réplique sur un disque identique pour ne pas saturer la sauvegarde avant le disque, voire plus grand si on garde un historique. C'est donc dommage de ne pas avoir pris un 250 à la place du 480 qui va être sous utilisé.

J'aurai fait un raid avec 2*250Go et externalisé sur un stockage distant sur un vieux hdd qui traine

+1 pour la logique: il vaut mieux mixer les technos surtout pour de la sauvegarde.

 
Compte tenu que tes usages impliquent peu d'écriture, y a vraiment pas besoin de t'emmerder. Les limites théoriques en écriture, c'est en centaines de To sur des SSD de 256/512 Go et c'est théorique : ça s'arrête pas le jour ou on dépasse, c'est juste que c'est plus garanti (les exemples montrent qu'on a une grosse :arge derrière).

Par contre faut du backup, on n'est jamais à l’abri d'un contrôleur qui défunte.
 
---
 
Rien à voir, un truc qui m'a rendu service sur mon pihole : https://www.reddit.com/r/pihole/com [...] ng_domain/
 
Le laptop du télétravail qui renvoyait des tas de warning, un petit fichier config à créer et apparemment ça résout le problème

Okay, pas besoin de s'emmerder avec un SSD plus grand juste pour avoir un peu plus de temps d'écriture vu mon usage. Cool bonne option. Dans mon cas, j'intervertirais pour avoir le 250Go en principal.  
 
@DannyElfman J'ai 2 RPI dont l'un est chez mes parents et l'autre chez moi. Actuellement hébergement NexCloud + Piwigo est chez mes parents qui ont une meilleure connexion. L'idée est justement de répliquer sur mon RPI chez moi.  
 
Je fais en quelques sortes du RAID 1. Dans l'idéal, en théorie, ce serait de faire du vrai RAID1 idéalement matériellement.  
Mais comme l'a bien compris Dandu, pour mon usage perso, il ne va pas y avoir de fort taux d'écriture. Une réplication régulière avec rsync semble être cohérent. En cas de crash de l'un des 2 disques, la majeure partie des données sont présentes sur l'autre.  
 
En matière de sauvegarde, je pensais partir sur un disque externe classique de 2To (c'est le minimum maintenant je crois), le brancher ponctuellement sur un de mes 2 RPI le temps de la sauvegarde.  
 
Je me dis qu'un disque dur ou SSD qui tourne le moins possible rallonge d'autant plus en théorie sa durée de vie (même si l'arret / démarrage n'est jamais très bon) . Bon par contre, il faut garder une certaine discipline et penser à le faire régulièrement.  
1 fois toutes les 2-3 semaines me semble être déjà pas mal comme fréquence d'autant plus qu'il y a réplication automatique.  
Et en matière de conservation d'historique, il y a de quoi faire avec 2 To sur 200Go

Hello,

Après quelques recherche j'arrive pas a me decider, quelle est la meilleure solution pour faire un "media center" pour quelqu'un.

C'est notamment pour Netflix, LibreElec ou OSMC, avec le module qui va bien etc... ? Ou même Android TV ?

Pas cher: prendre un petit pc thin client d'occasion avec un Haswell ou mieux Skylake dedans.
Plus cher: Nvidia Shield.
 
Dans les 2 cas c'est mieux qu'un Pi4.

Tu penses qu'un Pi4 2GB ne ferait pas l'affaire?

Apparemment à une époque c'était limite mais selon mes tests avec OSMC ou LibreElec ça passait bien. En plus, maintenant qu'on a du 64bits, possible que ça tourne mieux.

Pour moi il faut utiliser un firestick.
C'est moins de 40€ pour la version 4K max. Cela doit etre 30-35€ pour la version 4k, 25€ pour la version HD.
Il y a primevideo, netflix, disney+ en natif.
Tu peux installer Kodi très simplement. Il y a des tutos youtube.
 
Avec un pi tu va devoir installer une distribution, passer par kodi donc faire des bidouilles pour avoir netflix. De base tu n'aura pas de telecommande.
L'intégration n'a rien a voir.

Chez moi un pi 2go fait l'affaire, mais va trouver un raspberry avec plus d'un go de RAM de nos jours...
Édit : avec libreelec

 
C'est pas faux.