Pour le coup des disques durs qui flanchent simultanément, c'est exactement ce que je voulais dire : pour un NAS perso quand tu as un disque qui lâche tu peux te permettre de tout arrêter et d'attendre sagement le nouveau disque dur.
Dans une entreprise, j'imagine que tu ne peux pas demander aux employés de ranger leur bureau en attendant… ;-)
Au niveau emplacement, j'ai deux emplacements 2.5" et je peux éventuellement rajouter un petit SSD (format mSata ou un truc du genre) si je serre bien tout. Il faut que je voie si avec BTRFS c'est vraiment avantageux (pour ZFS j'ai lu le coup du ZIL et de L2ARC).
Je pense que cela va être intéressant pour moi de découvrir un nouveau FS.
Et bienvenue ! Tu verras que l'ambiance est sympa sur ce site. On y trouve pleins de bonnes infos même si parfois les discussions partent dans tous les sens.
Je ne peux donc pas me permettre financièrement trop de folies au niveau architecture. En particulier ce sera 2 disques durs maxi et éventuellement un SSD.
De plus il faut que la maintenance soit proche de zéro, en particulier lors des mises à jour du système et du noyau.
Il semblerait que ce soit un peu difficile de bien gérer la performance lorsque l'on active la déduplication donc je vais abandonner l'idée pour le moment.
Au niveau fiabilité, il semblerait que ZFS soit mieux (merci pour ton retour d'expérience). Au niveau maintenance, il semblerait que ce soit plus facile avec BTRFS. Mon coeur balance donc.
A noter que j'ai lu que BTRFS a inclus récemment une déduplication différée ou manuelle. Je vais creuser la question.
Si tu veux faire un journal sur le sujet, je pense qu'il sera très bien accueilli et tu auras potentiellement des commentaires intéressants sur ton architecture !
Le coup de l'alim de qualité je n'y avais même pas pensé (tu as des références à conseiller ?).
Pour les disques différents, je ne suis pas sûr : cela complique (un peu) l'administration (déjà que je me bats régulièrement avec mes WD sur le parquage des têtes) pour un gain relativement minime (je ne me souviens pas avoir entendu parler de disques qui claquent en même temps). Si une série est défectueuse, on a normalement le temps de changer le disque.
Pour l'extension possible avec des disques supplémentaires, en pratique ce sera impossible pour moi (pas de place physique dans le NAS perso). Donc il faut tout prévoir dès le début et ce sera je pense 2 disques dur (je suis pas sûr qu'ajouter un SSD soit très rentable pour du BTRFS, comme le coup du ZIL/L2ARC avec ZFS).
Franchement cela aurait valu un journal : je pense que d'autres auraient été bien intéressés.
Ok je te fais confiance, je vais essayer de partir au début sur BTRFS et voir si cela tient la route.
Si je vois que c'est trop instable, machine arrière sur ZFS.
Mon objectif est vraiment la fiabilité en premier, mais par contre je ne peux me permettre que 2 disques durs de 1 To (c'est pourquoi je regarde un ZFS ou BTRFS plutôt qu'un ext4).
Si le rapport investissement/gain est vraiment intéressant, je peux éventuellement ajouter un petit SSD.
Donc je suis assez limité au niveau du RAID possible. Je vais me renseigner pour voir comment optimiser cela avec BTRFS.
Merci pour les infos. Si l'expérience se révèle intéressante je ferai peut-être un journal !
Je me suis trompé pour la dédup au niveau d'un fichier : ZFS marche seulement avec de la dédup au niveau du bloc.
J'hésite réellement entre ZFS et BTRFS, mais je pencherais plutôt vers ZFS qui a l'air beaucoup plus stable actuellement.
BTRFS est sans aucun doute l'avenir mais j'ai quelques doutes sur sa stabilité actuelle.
Est-ce que tu as un bon retour d'expérience sur BTRFS ?
Pour une utilisation de NAS perso (i.e. données pas super critique mais c'est pas drôle de perdre ses photos, pas besoin d'une super performance, par contre besoin de très très peu de maintenance au niveau administration système et mis à jour), tu penses que c'est sans problème ?
Vu le sujet ce serait limite intéressant de faire un journal sur ton retour d'expérience ? ;-)
Est-ce que configurer ZFS pour de la dédup au niveau du fichier ou au niveau du bloc change quelque chose au niveau des performances ou au niveau de la RAM nécessaire ?
Il me semble que cela doit être plus light pour de la dédup au niveau du fichier.
Je suis avec intérêt BTRFS mais il semble que ce ne soit pas assez stable à mon goûts et je souhaite avant tout la stabilité.
Je n'ai pas trouvé beaucoup de retour d'expérience récent avec ZFS et Debian stable (ou testing).
Les nouveaux noyaux ne sont pas si nombreux si on tourne avec Debian stable, donc effectivement peut-être que ZFS serait idéal dans ce cas là.
D'abord, je ne crache pas sur la personne mais (un peu) sur les commentateurs qui ont laissé leur esprit critique au garage.
Ok c'est donc moi que tu visais.
Je n'ai pas laissé mon esprit critique au placard mais j'ai l'impression que contrairement à toi je ne me focalise pas sur la pertinence des technologies derrières et sur la qualité du code.
L'auteur vient nous présenter son projet personnel, nous explique sa démarche et présente ses résultats. Je trouve l'ensemble très intéressant et suis effectivement impressionné par le fait qu'il ait travaillé par tranche de 20 mn-2h (moi aussi je n'ai pas beaucoup de temps pour mes projets perso et je dois aussi travailler avec ce genre de contraintes et je sais à quel point cela peut être limitant).
Je pense donc que tu t'emportes un peu vite et te trompe un peu sur l'objectif de mon commentaire. Mon but n'était pas de donner un avis sur son professionnalisme, sur la qualité du produit, ou son adéquation par rapport au standard requis de l'industrie. Mon but était plutôt de donner mon avis sur sa démarche (personnellement j'en ai choisi une autre qui est de contribuer à l'existant).
En gros je salue l'effort et toi tu dis simplement "bof on peut faire mieux et plus vite".
Moi aussi je ne trouvais pas mon bonheur dans les outils libres actuels de gestion de tickets.
D'ailleurs même dans les outils propriétaires, je n'ai pas été totalement convaincu (JIRA est pas mal quand même).
N'ayant pas les compétences pour démarrer quelque chose de zéro, je voulais plutôt contribuer pour orienter le développement de logiciels libres vers quelque chose de plus adapté à mon besoin.
Mon choix s'est vite restreint à Redmine et à Trac. Étant plus Python que Ruby, j'ai donc commencé à contribuer à Trac et à Apache Bloodhound (qui est une sorte de fork amical de Trac intégrant entre autre la gestion de plusieurs projets). Bon pour l'instant il y a plus de traduction que de code, mais c'est une manière pour moi de me familiariser avec le projet.
En tout cas je souhaite longue vie à ton projet !
C'est assez impressionnant de voir ce que tu as réussi à faire en moins d'un an avec des tranches de 20 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…
Les deux exemples montrent que si tu "corriges" un des deux aspects (délai avant parquage ou process parasite) en négligeant l'autre aspect, tu obtiens un comportement insatisfaisant dans certains cas d'utilisation.
Donc au final, pour avoir un comportement satisfaisant il faut vérifier qu'il n'y a pas de process parasite et régler son délai avant parquage à une valeur adaptée à son utilisation.
Pour une utilisation bittorrent: 5 mn c'est pas mal.
Pour un portable: je crois qu'effectivement les 8 s des WD c'était pour protéger le disque en cas de choc (dans ce cas 5 mn c'est vraiment trop).
Pour un NAS en environnement pro qui doit répondre assez vite: je mettrais 2-3h (histoire qu'il s'arrête la nuit)
Comme process parasite rigolo, j'ai eu mon lot de surprises : firefox qui synchronisait toutes les 30s, des process qui loggaient pour pas grand chose (--mark-- dans syslog), des CRON se déclenchant toutes les heures sans réelle utilité, etc.
Bref arriver à avoir un système GNU/linux qui se mette en idle, c'est pas vraiment facile !
A noter que régler le délai avant parquage des têtes est un défi en soi.
Avec mon WD je n'ai toujours pas réussi à avoir ce que je voulais.
Et pourtant j'ai essayé à grand coup de hdparm et de idle3 mais il ne veut rien savoir. Au final j'ai baissé les bras, et me suis résigné à le voir tourner en permanence sans parquage.
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.
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.
Oui tu as raison, les deux problèmes sont en fait aussi importants l'un que l'autre.
Je suppose que dans l'idéal il faudrait pouvoir régler le délai avant parquage des têtes en fonction de son utilisation du NAS. 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.
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 :-)
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.
À mon avis c'est un double problème : tu as un process qui réveille le disque en permanence + un mauvais réglage qui est trop agressif sur la mise en veille du disque.
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).
J'avoue trouver le business model de Paymill assez "original" (je crois que c'est cloner un service et se faire racheter, cf. Rocket company et Samwer brothers), mais si tout le monde y trouve son compte, pourquoi pas.
Ah tiens je voulais justement initier une dépêche sur le sujet (je ne sais pas si cela intéresse beaucoup de monde cependant).
Je suis aussi parti sur Salt, pour ceux que cela intéresse il y a aussi Salty Vagrant qui est très intéressant et Ansible, un sérieux concurrent de Salt (les différences entre les deux sont assez intéressantes).
Tu as cela de base je crois. En tout cas tu peux générer un planning global avec toutes les ressources et tous les horaires. Je crois bien qu'il est aussi possible de générer un xml en sortie ou un truc dans le genre (c'est facile ensuite d'extraire ce qui t'intéresse).
C'est plus un outil de planification, mais tu peux jeter un oeil sur Taskjuggler.
Contrairement à Microsoft Project, il permet de créer des taches, des contraintes et des ressources et d'allouer automatiquement les ressources aux taches en respectant les contraintes et en optimisant l'usage des ressources.
Par contre tout est configuratble via un vulgaire fichier texte, donc si tu cherches plutôt une interface graphique sexy, passe ton chemin. Par contre il peut générer en sortie un planning assez beau (et interactif).
Perso après 10 jours à essayer de gérer un projet compliqué avec Microsoft Project, j'ai réussi à le faire avec Taskjuggler en moins de 2 jours.
Mais physiquement mon toto est dans /var/www/var/www/toto (j'ai même laissé un toto dans /var/www/toto au cas où).
Donc cela devrait marcher ?
Mon Directory donné (/var/www/toto) devrait donc être bon ?
Je n'ai pas trouvé de DocumentRoot de base dans mes fichiers de conf d'Apache donc je ne l'ai pas laissé dans le httpd.conf dans mon exemple. Par contre j'avais essayé de mettre "DocumentRoot /" et cela n'a rien changé (c'est peut-être la valeur par défaut de DocumentRoot ?).
Mais si je déplace directement le répertoire de mon site dans le chemin utilisé par le chroot, cela ne suffit pas ?
Je voulais justement éviter dans un premier temps toutes ces histoires de liens symboliques, hard, mount et autres (pour déboguer) donc j'ai directement déplacé le répertoire pour voir si cela marchait.
Ou bien est-ce qu'il y a une subtilité que je n'ai pas comprise ?
J'avais bien essayé cette solution mais quel que soit les options que je mets (FollowSymLinks ou pas) j'ai toujours le message d'erreur :
Symbolic link not allowed or link target not accessible: /var/www
C'est pourquoi j'ai tenté de mettre directement le répertoire dans le chroot sans utiliser de liens symboliques. Et même dans ce cas cela ne marche pas, mais cette fois avec un autre message d'erreur (client denied by server configuration: /var ).
J'ai beaucoup utilisé Matplotlib lors de ses débuts et John Hunter a toujours toujours trouvé le temps de répondre à mes questions avec gentillesse et pédagogie.
Depuis un bon moment, la qualité de sa bibliothèque Matplotlib était telle que je n'avais plus besoin de poser de questions ou de remonter des bogues mais je le sentais toujours présent, toujours à ajouter de nouvelles fonctionnalités ou à aider les débutants.
Il représente à lui tout seul une bonne part des raisons qui m'ont fait aimer le monde libre et il figurera toujours pour moi dans mon panthéon personnel des modèles à suivre.
Je vais aller effectuer une donation sans tarder pour aider sa famille.
Même si je n'écris pas pour obtenir des cadeaux ou de la reconnaissance cela va m'encourager à contribuer un peu plus !
J'ai souvent quelque remords à lire autant et à contribuer si peu…
Je ne sais pas pour vous, mais pour moi une journée sans nouvelle dépêche ou nouveau journal, c'est un peu comme une journée sans pain (je n'ai pas regardé les stats mais cela ne doit pas arriver souvent).
J'ai lu les précédentes dépêche concernant Ultracopier et je dois avouer être assez déçu par la réaction de certains.
L'auteur d'Ultracopier est loin d'être parfait mais il a au moins fait l'effort de contribuer de manière concrète au monde libre. Alors on peut lui reprocher beaucoup de choses mais voilà, au bout du compte son logiciel (qui semble très intéressant qui plus est) est disponible sous GPL3.
Personnellement vu le mal que j'ai à me motiver pour travailler/coder après une journée de travail, je suis admiratif devant ce genre de personnes.
J'ai aussi été légèrement gêné par les nombreuses fautes sur le site web, mais je ne me suis pas plains. Si cela me gênait vraiment, j'aurais plutôt contribué et corrigé (l'auteur a d'ailleurs appelé à l'aide pour corriger son texte).
Quant à l'aspect pécunier, je suis toujours étonné de voir à quel point il est difficile de faire accepter que certains souhaitent gagner de l'argent avec le libre.
Pour ma part je n'ai souvent pas le temps et/ou l'envie de coder, écrire la doc, remonter les bogues, etc. Si j'aime bien un projet, je donne un peu de sous et tout le monde est content (et cela me donne moins l'impression d'être un profiteur).
En conclusion, des remarques constructives seraient plus bienvenues que des attaques agressives.
[^] # Re: petit retour d'exp
Posté par SaintGermain . En réponse au message ZFS performance et déduplication. Évalué à 2.
Pour le coup des disques durs qui flanchent simultanément, c'est exactement ce que je voulais dire : pour un NAS perso quand tu as un disque qui lâche tu peux te permettre de tout arrêter et d'attendre sagement le nouveau disque dur.
Dans une entreprise, j'imagine que tu ne peux pas demander aux employés de ranger leur bureau en attendant… ;-)
Au niveau emplacement, j'ai deux emplacements 2.5" et je peux éventuellement rajouter un petit SSD (format mSata ou un truc du genre) si je serre bien tout. Il faut que je voie si avec BTRFS c'est vraiment avantageux (pour ZFS j'ai lu le coup du ZIL et de L2ARC).
Je pense que cela va être intéressant pour moi de découvrir un nouveau FS.
Merci !
[^] # Re: petit retour d'expérience en ZFS
Posté par SaintGermain . En réponse au message ZFS performance et déduplication. Évalué à 2.
Salut !
Merci pour ton avis, c'est sympa.
Et bienvenue ! Tu verras que l'ambiance est sympa sur ce site. On y trouve pleins de bonnes infos même si parfois les discussions partent dans tous les sens.
Pour la déduplication à des fins de sauvegarde, j'ai écris une dépêche sur le sujet il y a un moment, peut-être que cela t'intéressera :
http://linuxfr.org/news/r-evolutions-dans-le-monde-de-la-sauvegarde-de-donnees
Je ne peux donc pas me permettre financièrement trop de folies au niveau architecture. En particulier ce sera 2 disques durs maxi et éventuellement un SSD.
De plus il faut que la maintenance soit proche de zéro, en particulier lors des mises à jour du système et du noyau.
Il semblerait que ce soit un peu difficile de bien gérer la performance lorsque l'on active la déduplication donc je vais abandonner l'idée pour le moment.
Au niveau fiabilité, il semblerait que ZFS soit mieux (merci pour ton retour d'expérience). Au niveau maintenance, il semblerait que ce soit plus facile avec BTRFS. Mon coeur balance donc.
A noter que j'ai lu que BTRFS a inclus récemment une déduplication différée ou manuelle. Je vais creuser la question.
Si tu veux faire un journal sur le sujet, je pense qu'il sera très bien accueilli et tu auras potentiellement des commentaires intéressants sur ton architecture !
[^] # Re: petit retour d'exp
Posté par SaintGermain . En réponse au message ZFS performance et déduplication. Évalué à 2.
Mais c'est une mine d'or tes posts ! ;-)
Le coup de l'alim de qualité je n'y avais même pas pensé (tu as des références à conseiller ?).
Pour les disques différents, je ne suis pas sûr : cela complique (un peu) l'administration (déjà que je me bats régulièrement avec mes WD sur le parquage des têtes) pour un gain relativement minime (je ne me souviens pas avoir entendu parler de disques qui claquent en même temps). Si une série est défectueuse, on a normalement le temps de changer le disque.
Pour l'extension possible avec des disques supplémentaires, en pratique ce sera impossible pour moi (pas de place physique dans le NAS perso). Donc il faut tout prévoir dès le début et ce sera je pense 2 disques dur (je suis pas sûr qu'ajouter un SSD soit très rentable pour du BTRFS, comme le coup du ZIL/L2ARC avec ZFS).
Franchement cela aurait valu un journal : je pense que d'autres auraient été bien intéressés.
Merci beaucoup !
[^] # Re: petit retour d'exp
Posté par SaintGermain . En réponse au message ZFS performance et déduplication. Évalué à 2.
Ok je te fais confiance, je vais essayer de partir au début sur BTRFS et voir si cela tient la route.
Si je vois que c'est trop instable, machine arrière sur ZFS.
Mon objectif est vraiment la fiabilité en premier, mais par contre je ne peux me permettre que 2 disques durs de 1 To (c'est pourquoi je regarde un ZFS ou BTRFS plutôt qu'un ext4).
Si le rapport investissement/gain est vraiment intéressant, je peux éventuellement ajouter un petit SSD.
Donc je suis assez limité au niveau du RAID possible. Je vais me renseigner pour voir comment optimiser cela avec BTRFS.
Merci pour les infos. Si l'expérience se révèle intéressante je ferai peut-être un journal !
Bonne soirée
[^] # Re: petit retour d'exp
Posté par SaintGermain . En réponse au message ZFS performance et déduplication. Évalué à 2.
Je me suis trompé pour la dédup au niveau d'un fichier : ZFS marche seulement avec de la dédup au niveau du bloc.
J'hésite réellement entre ZFS et BTRFS, mais je pencherais plutôt vers ZFS qui a l'air beaucoup plus stable actuellement.
BTRFS est sans aucun doute l'avenir mais j'ai quelques doutes sur sa stabilité actuelle.
Est-ce que tu as un bon retour d'expérience sur BTRFS ?
Pour une utilisation de NAS perso (i.e. données pas super critique mais c'est pas drôle de perdre ses photos, pas besoin d'une super performance, par contre besoin de très très peu de maintenance au niveau administration système et mis à jour), tu penses que c'est sans problème ?
Vu le sujet ce serait limite intéressant de faire un journal sur ton retour d'expérience ? ;-)
Merci encore !
[^] # Re: petit retour d'exp
Posté par SaintGermain . En réponse au message ZFS performance et déduplication. Évalué à 2.
Très intéressant retour, merci !
Est-ce que configurer ZFS pour de la dédup au niveau du fichier ou au niveau du bloc change quelque chose au niveau des performances ou au niveau de la RAM nécessaire ?
Il me semble que cela doit être plus light pour de la dédup au niveau du fichier.
Je suis avec intérêt BTRFS mais il semble que ce ne soit pas assez stable à mon goûts et je souhaite avant tout la stabilité.
Je n'ai pas trouvé beaucoup de retour d'expérience récent avec ZFS et Debian stable (ou testing).
Les nouveaux noyaux ne sont pas si nombreux si on tourne avec Debian stable, donc effectivement peut-être que ZFS serait idéal dans ce cas là.
Merci encore !
[^] # Re: Absurde
Posté par SaintGermain . En réponse au journal Small Issue Tracker. Évalué à 2.
Ok c'est donc moi que tu visais.
Je n'ai pas laissé mon esprit critique au placard mais j'ai l'impression que contrairement à toi je ne me focalise pas sur la pertinence des technologies derrières et sur la qualité du code.
L'auteur vient nous présenter son projet personnel, nous explique sa démarche et présente ses résultats. Je trouve l'ensemble très intéressant et suis effectivement impressionné par le fait qu'il ait travaillé par tranche de 20 mn-2h (moi aussi je n'ai pas beaucoup de temps pour mes projets perso et je dois aussi travailler avec ce genre de contraintes et je sais à quel point cela peut être limitant).
Je pense donc que tu t'emportes un peu vite et te trompe un peu sur l'objectif de mon commentaire. Mon but n'était pas de donner un avis sur son professionnalisme, sur la qualité du produit, ou son adéquation par rapport au standard requis de l'industrie. Mon but était plutôt de donner mon avis sur sa démarche (personnellement j'en ai choisi une autre qui est de contribuer à l'existant).
En gros je salue l'effort et toi tu dis simplement "bof on peut faire mieux et plus vite".
# Très bonne idée
Posté par SaintGermain . En réponse au journal Small Issue Tracker. Évalué à 5.
Moi aussi je ne trouvais pas mon bonheur dans les outils libres actuels de gestion de tickets.
D'ailleurs même dans les outils propriétaires, je n'ai pas été totalement convaincu (JIRA est pas mal quand même).
N'ayant pas les compétences pour démarrer quelque chose de zéro, je voulais plutôt contribuer pour orienter le développement de logiciels libres vers quelque chose de plus adapté à mon besoin.
Mon choix s'est vite restreint à Redmine et à Trac. Étant plus Python que Ruby, j'ai donc commencé à contribuer à Trac et à Apache Bloodhound (qui est une sorte de fork amical de Trac intégrant entre autre la gestion de plusieurs projets). Bon pour l'instant il y a plus de traduction que de code, mais c'est une manière pour moi de me familiariser avec le projet.
En tout cas je souhaite longue vie à ton projet !
C'est assez impressionnant de voir ce que tu as réussi à faire en moins d'un an avec des tranches de 20 mn.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par SaintGermain . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 1.
J'essaye toujours de remonter les problèmes quand je peux :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710803
(là pour le coup c'est pas upstream le problème mais un patch Debian)
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par SaintGermain . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 3.
Les deux exemples montrent que si tu "corriges" un des deux aspects (délai avant parquage ou process parasite) en négligeant l'autre aspect, tu obtiens un comportement insatisfaisant dans certains cas d'utilisation.
Donc au final, pour avoir un comportement satisfaisant il faut vérifier qu'il n'y a pas de process parasite et régler son délai avant parquage à une valeur adaptée à son utilisation.
Pour une utilisation bittorrent: 5 mn c'est pas mal.
Pour un portable: je crois qu'effectivement les 8 s des WD c'était pour protéger le disque en cas de choc (dans ce cas 5 mn c'est vraiment trop).
Pour un NAS en environnement pro qui doit répondre assez vite: je mettrais 2-3h (histoire qu'il s'arrête la nuit)
Comme process parasite rigolo, j'ai eu mon lot de surprises : firefox qui synchronisait toutes les 30s, des process qui loggaient pour pas grand chose (--mark-- dans syslog), des CRON se déclenchant toutes les heures sans réelle utilité, etc.
Bref arriver à avoir un système GNU/linux qui se mette en idle, c'est pas vraiment facile !
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par SaintGermain . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
Tu m'enlèves les mots de la bouche. ;-)
A noter que régler le délai avant parquage des têtes est un défi en soi.
Avec mon WD je n'ai toujours pas réussi à avoir ce que je voulais.
Et pourtant j'ai essayé à grand coup de hdparm et de idle3 mais il ne veut rien savoir. Au final j'ai baissé les bras, et me suis résigné à le voir tourner en permanence sans parquage.
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.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par SaintGermain . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 3.
Oui tu as raison, les deux problèmes sont en fait aussi importants l'un que l'autre.
Je suppose que dans l'idéal il faudrait pouvoir régler le délai avant parquage des têtes en fonction de son utilisation du NAS. 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.
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.
# Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par SaintGermain . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 7.
Bon ok j'exagère un peu avec mon titre.
À mon avis c'est un double problème : tu as un process qui réveille le disque en permanence + un mauvais réglage qui est trop agressif sur la mise en veille du disque.
Certains Western Digital sont réputés pour l'agressivité de leur mise en veille :
https://wiki.archlinux.org/index.php/Advanced_Format#Special_Consideration_for_WD_Green_HDDs
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).
[^] # Re: Ansible et Salty Vagrant
Posté par SaintGermain . En réponse à la dépêche SaltStack Meetup à l'Open World Forum. Évalué à 1.
Salt et Ansible semblent très bien tous les deux : c'est apparemment une grande amélioration par rapport aux outils existants.
Quelques points de comparaison (surtout les commentaires) :
- http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/
- https://news.ycombinator.com/item?id=5932608
Pour compléter ma remarque sur Salty Vagrant, du côté d'Ansible c'est directement intégré dans Vagrant (non testé cependant) :
- http://docs.vagrantup.com/v2/provisioning/ansible.html-
[^] # Re: Paymill
Posté par SaintGermain . En réponse au message Alternatives à Paypal. Évalué à 1.
Stripe est disponible en beta privée pour la France:
https://support.stripe.com/questions/is-stripe-available-in-france-how-do-i-sign-up-for-the-beta
J'avoue trouver le business model de Paymill assez "original" (je crois que c'est cloner un service et se faire racheter, cf. Rocket company et Samwer brothers), mais si tout le monde y trouve son compte, pourquoi pas.
# Ansible et Salty Vagrant
Posté par SaintGermain . En réponse à la dépêche SaltStack Meetup à l'Open World Forum. Évalué à 2.
Ah tiens je voulais justement initier une dépêche sur le sujet (je ne sais pas si cela intéresse beaucoup de monde cependant).
Je suis aussi parti sur Salt, pour ceux que cela intéresse il y a aussi Salty Vagrant qui est très intéressant et Ansible, un sérieux concurrent de Salt (les différences entre les deux sont assez intéressantes).
[^] # Re: Taskjuggler
Posté par SaintGermain . En réponse au journal A la recherche d'un programme de gestion d'événement et de planification. Évalué à 1.
Tu as cela de base je crois. En tout cas tu peux générer un planning global avec toutes les ressources et tous les horaires. Je crois bien qu'il est aussi possible de générer un xml en sortie ou un truc dans le genre (c'est facile ensuite d'extraire ce qui t'intéresse).
# Taskjuggler
Posté par SaintGermain . En réponse au journal A la recherche d'un programme de gestion d'événement et de planification. Évalué à 4.
C'est plus un outil de planification, mais tu peux jeter un oeil sur Taskjuggler.
Contrairement à Microsoft Project, il permet de créer des taches, des contraintes et des ressources et d'allouer automatiquement les ressources aux taches en respectant les contraintes et en optimisant l'usage des ressources.
Par contre tout est configuratble via un vulgaire fichier texte, donc si tu cherches plutôt une interface graphique sexy, passe ton chemin. Par contre il peut générer en sortie un planning assez beau (et interactif).
Perso après 10 jours à essayer de gérer un projet compliqué avec Microsoft Project, j'ai réussi à le faire avec Taskjuggler en moins de 2 jours.
[^] # Re: FollowSymLinks
Posté par SaintGermain . En réponse au message Monter Apache2 dans un chroot sous Debien Squeeze. Évalué à 1.
Mais physiquement mon toto est dans /var/www/var/www/toto (j'ai même laissé un toto dans /var/www/toto au cas où).
Donc cela devrait marcher ?
Mon Directory donné (/var/www/toto) devrait donc être bon ?
Je n'ai pas trouvé de DocumentRoot de base dans mes fichiers de conf d'Apache donc je ne l'ai pas laissé dans le httpd.conf dans mon exemple. Par contre j'avais essayé de mettre "DocumentRoot /" et cela n'a rien changé (c'est peut-être la valeur par défaut de DocumentRoot ?).
Merci pour le coup de main en tout cas !
[^] # Re: FollowSymLinks
Posté par SaintGermain . En réponse au message Monter Apache2 dans un chroot sous Debien Squeeze. Évalué à 1.
Mais si je déplace directement le répertoire de mon site dans le chemin utilisé par le chroot, cela ne suffit pas ?
Je voulais justement éviter dans un premier temps toutes ces histoires de liens symboliques, hard, mount et autres (pour déboguer) donc j'ai directement déplacé le répertoire pour voir si cela marchait.
Ou bien est-ce qu'il y a une subtilité que je n'ai pas comprise ?
[^] # Re: FollowSymLinks
Posté par SaintGermain . En réponse au message Monter Apache2 dans un chroot sous Debien Squeeze. Évalué à 1.
Bonjour !
J'avais bien essayé cette solution mais quel que soit les options que je mets (FollowSymLinks ou pas) j'ai toujours le message d'erreur :
C'est pourquoi j'ai tenté de mettre directement le répertoire dans le chroot sans utiliser de liens symboliques. Et même dans ce cas cela ne marche pas, mais cette fois avec un autre message d'erreur (client denied by server configuration: /var ).
D'autres idées ?
Merci pour ton aide !
[^] # Re: Dépêche
Posté par SaintGermain . En réponse au journal Le principe KISS appliqué à la gestion des sauvegardes.. Évalué à 3.
Bah oui j'avais déjà parlé de BURP (et de BackupPC) dans ma dépêche…
Heureusement qu'il y en a qui suivent ! ;-)
# Une énorme perte
Posté par SaintGermain . En réponse à la dépêche Décès de John Hunter, créateur de matplotlib. Évalué à 8.
J'ai beaucoup utilisé Matplotlib lors de ses débuts et John Hunter a toujours toujours trouvé le temps de répondre à mes questions avec gentillesse et pédagogie.
Depuis un bon moment, la qualité de sa bibliothèque Matplotlib était telle que je n'avais plus besoin de poser de questions ou de remonter des bogues mais je le sentais toujours présent, toujours à ajouter de nouvelles fonctionnalités ou à aider les débutants.
Il représente à lui tout seul une bonne part des raisons qui m'ont fait aimer le monde libre et il figurera toujours pour moi dans mon panthéon personnel des modèles à suivre.
Je vais aller effectuer une donation sans tarder pour aider sa famille.
Merci pour la dépêche.
# Un grand merci
Posté par SaintGermain . En réponse à la dépêche Meilleurs contributeurs LinuxFr.org : les gagnants de juin 2012. Évalué à 4.
C'est vraiment sympa, merci !
Même si je n'écris pas pour obtenir des cadeaux ou de la reconnaissance cela va m'encourager à contribuer un peu plus !
J'ai souvent quelque remords à lire autant et à contribuer si peu…
Je ne sais pas pour vous, mais pour moi une journée sans nouvelle dépêche ou nouveau journal, c'est un peu comme une journée sans pain (je n'ai pas regardé les stats mais cela ne doit pas arriver souvent).
[^] # Re: Boutique
Posté par SaintGermain . En réponse à la dépêche Version finale d'ultracopier 0.3. Évalué à 10.
J'ai lu les précédentes dépêche concernant Ultracopier et je dois avouer être assez déçu par la réaction de certains.
L'auteur d'Ultracopier est loin d'être parfait mais il a au moins fait l'effort de contribuer de manière concrète au monde libre. Alors on peut lui reprocher beaucoup de choses mais voilà, au bout du compte son logiciel (qui semble très intéressant qui plus est) est disponible sous GPL3.
Personnellement vu le mal que j'ai à me motiver pour travailler/coder après une journée de travail, je suis admiratif devant ce genre de personnes.
J'ai aussi été légèrement gêné par les nombreuses fautes sur le site web, mais je ne me suis pas plains. Si cela me gênait vraiment, j'aurais plutôt contribué et corrigé (l'auteur a d'ailleurs appelé à l'aide pour corriger son texte).
Quant à l'aspect pécunier, je suis toujours étonné de voir à quel point il est difficile de faire accepter que certains souhaitent gagner de l'argent avec le libre.
Pour ma part je n'ai souvent pas le temps et/ou l'envie de coder, écrire la doc, remonter les bogues, etc. Si j'aime bien un projet, je donne un peu de sous et tout le monde est content (et cela me donne moins l'impression d'être un profiteur).
En conclusion, des remarques constructives seraient plus bienvenues que des attaques agressives.