jben a écrit 841 commentaires

Tant qu'à faire, pourquoi effacer des lignes sauf celles qui matchent, et ne pas raisonner en affichant seulement celles qui matchent ?

df -iPh | sed -ne '/[5-9][0-9]\%/p'

Explications :

• -ndesactive l'affichage auto,
• celles qui matchent se font afficher.

Wait… en fait c'est un grep !

D'ailleurs moi quand je parse une sortie d'une commande, je n'aime pas être géné par une éventuelle localisation qui viendrait perturber mon résultat, j'ai donc toujours un LANG=C.

Mais sinon sur la question intiale, j'approuve le premier commentaire, une solution de suppervision (même si moi je pense à munin) me parrait vraiment plus adaptée pour ce genre de choses.

Merde quoi! c'est culoté quand même : journal posté à 22h44, premier commentaire pour se plaindre : 22h52. Le mec il n'a pas lu 3 lignes ?

Merci, mais tu as oublié une possibilité : je l'avais déjà lu.

J'ai mon avis sur le contenu, je l'ai précisé en première ligne de mon commentaire. Je ne critique pas le contenu, je critique son inadéquation avec les sujets couramment abordés ici. J'aurai compris si il y avait une réelle plus-value (comme une traduction, un début de débat, une argumentation…), mais là, je reste dubitatif.

J'ai cliqué sur le lien, je connaissais le sujet, j'avais déjà lu ce témoignage.

Cela ne m'avait pas choqué quand je l'avais lu à l'époque. C'est vrai que quand on compare les deux versions, celle-ci est plus lisible.

Je vais donc dire que la valeur ajoutée est faible par rapport à la valeur ajouté qu'aurait pu lui apporter l'auteur du journal. En à mon avis trop faible pour justifier de faire un journal hors-sujet.

Non pas que le propos soit ininteressant, mais je me poses des questions sur sa place ici.

Tu aurais pu avoir une valeur ajoutée, par exemple le traduire, mais là rien, aucune valeur ajoutée par rapport à un lien. Déja que j'aurai douté de la pertinence d'un journal bookmark sur le sujet, mais nous faire une copie sans valeur ajouté est completement inutile.

Bref, pour ton premier journal, tu essaie d'avoir une borne inférieure pour faire mieux ensuite ?

Tout simplement, tu fais un script qui fait l'action sur une IP donnée en argument, genre action_sur_IP :

#!/bin/bash

IP=$1
# Je fais plein de truc avec $IP

Puis après tu lances tout avec xargs, genre

xargs -n 1 -P 0 ./action_sur_IP < ip.cfg

Et hop, ça roule.

En jouant avec le -P tu peux décider combien de processus tu execute en paralelle (-P 0 veut dire autant qu'il y a de processus à lancer, donc tout en même temps).

Je le répète mon intention en disant pour moi n'est pas de prendre les gens de haut, mais d'éviter de tirer une géneralité de mon comportement.

Si c'est tuner son noyau […]

Le tunning de noyau à mes yeux (pour ne pas dire pour moi), c'est des truc un peu plus violent comme appliquer un patch pour transformer l'appel système fsync en truc qui ne fait rien. D'ailleurs la blague c'est que ce comportement est POSIX-compliant. À ce propos un thread en parle sur la lkml. Notez bien que je n'approuve pas ce patch, bien que je trouve que les applications utilisent fsync à tord et à travers, il y a des cas où cet appel est justifié, l'usage d'une solution comme eat-my-data sur les programmes en faisant un usage non justifié, me semble préferable.

Tu augmente la quantité de pages sales que le noyau accepte. Ça reviens à augmenter le buffer de lecture (comme tu l'a bien dis les écritures sont asynchrones donc on s'en fout). Dans les fait comment ça se passe ? Si tu fais un read(fd, buff, SIZE); le noyau va se permettre de lire plus préventivement ? ou est-ce que ça s'applique principalement sur des appels comme mmap ?

Augmenter la quantité de pages sales autorisée ne reviens pas à augmenter le buffer de lecture, c'est uniquement les ecritures qui sont plus bufferisés. Donc la lecture devient la seule chose à faire à ce moment.

Lorsque tu parles de lecture préventive, c'est plus au niveau du readahead qu'il faut aller voir, et donc du coté de hdparm. À noter que laptop-mode-tools permet aussi de facilement gerer ce comportement sans aller manger la doc de hdparm qui n'est pas des plus digestes.

Par contre pour les gros fichiers (ceux qui sont trop gros pour que tu les mettent en cache), il vaut mieux utiliser une technique comme ultracopier, car il faut que l'utilisateur voit pourquoi son fichier n'est pas entrain d'être lu et qu'il puisse mettre en pause la copie qui le bloque (parce que la première est moins prioritaire pour lui). Bien sûr tu peut faire un Ctr+z sur le cp en question, mais c'est moins pratique il faut savoir que c'est bien lui qui bloque.

Pour le coup, je suis très rarement confronté à ce genre de problème. Je l'étais à une époque, mais j'ai pris l'habitude (en partie grâce au fait que je suis ammené à travailler sur des machines dont je ne suis pas le seul utilisateur) d'utiliser ionice. Quand j'ai besoin d'effectuer une tache gourmande en I/O, et que j'estime cette tache non prioritaire, je la lance en class idle pour ionice (à l'aide d'un ionice -c 3, j'ai un alias). Il m'arrive aussi de redefinir un l'ionice d'un processus déjà lancé.

Et tu ne vérifie pas que la copie de ta sauvegarde c'est bien faite ? Si c'est le cas c'est dommage.

Si bien sûr, avec l'outil de transfert, une vérification périodique des checksum est effectuée.

Mais ce qui est vraiment dommage c'est de te voir depuis 2 jours aligner les "moi je …" tune mon noyau, n'est pas besoin de… etc en prenant un peu tout le monde de haut.

Au lieu d'utiliser ce genre d'arguments, je sais que la forme de mon discours est perfectible, pourrais-tu répondre sur le fond ? Je parle de ce qui doit être fait par le noyau et fait par les programmes en espace utilisateur ? J'ai une opinion, je l'exprime comme étant la mienne sans généraliser, il est vrai que je pourrais l'exprimer différement.

Et ce n'est pas tuner son noyau de choisir des valeurs adaptées à son usage. D'ailleurs des programmes permettent très facilement de régler ce genre de chose, par exemple laptop-mode-tools.

J'ai du mal à comprendre en quoi la fiabilité est meilleure. Quand j'ai besoin de copier des données en local sur un média, j'y vais à coup de cp, sync, démontage. Dès que c'est à distance, rsync est mon seul ami.

De toutes les façons vu le peu de copies local de fichier que j'effectue, genre en local pour mes fichiers j'utilise un gestionnaire de version, ça me suffit.

Bref, à part le point interface et convivialité du bestiaux qui ne m'interesse pas (mais ça c'est mon coté refractaire, c'était mieux à vents), je n'arrive toujours pas à voir pourquoi un gestionnaire de copie pourrait m'être utile.

1er point c'est la fiabilité de la copie (peu de personne prenne en compte ce point jusqu’à ce qu'il perdent leur données).

Moi je ne considère pas un disque comme fiable. Je dois être parano. Donc pour moi, écrire de manière fiable sur un support qu'il ne l'est pas, ce n'est pas très utile. Pour cela j'utilise d'autres solutions pour garantir la pérennité de mes données (comme des sauvegardes délocalisées)

Moi j'aimerai bien un moyen de désactivé la possibilité de faire un sync sous linux (pas la commande, mais l'appelle système). Car dans un env KDE, 95% des applications font un sync à chaque close, et en plus certaine application ferme et ouvre des fichiers sans arrêt.

Il existe une lib chargeable en LIB_LD_PRELOAD pour cela. Ils fournissent même un wrapper pour ne pas avoir à faire le preload à la main. C'est libeatmydata.

C'est à utiliser en connaissance de cause bien sûr.

Je tiens à préciser quelque chose:
Dans l'ensemble, quand ont reste dans le cache/buffer, tout les systémes ont à peu prêt les mêmes caractéristiques.

Par contre, quand le buffer/cache est trop petit, la, la différence coté application ET coté OS se fait (réorganisation des accès hdd).

Donc en gros, tu es d'accord avec moi, si on a un cache et des buffers configurés de tel sorte qu'ils soient suffisamment gros (donc avec de la RAM en face), l'utilisation d'un gestionnaire de copie est inutile. Sans vouloir dénigrer les gestionnaires de copies, ça reste du rustinage pour les systèmes matériellement limités où le noyau ne peut pas faire bien son boulot.

Qt fait un sync à chaque close() de chaque fichier

Je te rejoins complètement sur cette critique, mais pour des raisons radicalement différentes. Toi tu fais un boulot qui devrait normalement être effectué par le noyau et ce comportement te gène. De mon coté, bien que je pense qu'il est normal que depuis l'espace utilisateur on puisse demander un sync pour vider écrire les pages sales, cela reste un besoin extrêmement spécifique, et à mon avis les programmes ne devraient pas, sauf exceptions, interférer avec la politique d'écriture du noyau.

Par exemple sur mon notebook, j'ai une politique extrêmement agressive de gestion de l'énergie, en particulier j'ai une expiration des pages sales de 30 minutes. Je sais ce que je fais, c'est mon choix, ça correspond à mon usage. Je ne veux pas que les programmes s'occupe du boulot du noyau, c'est le boulot du noyau, j'ai configuré ce qu'il faut pour, les programmes : laissez faire le noyau.

Et je me répond à moi-même, pour préciser que dans le cas où les données à copier sont en cache, on observe des résultats similaires :

Pour le séquentiel :

rm -rf qqpart; mkdir qqpart; sync; res; cat qqch?/* > /dev/null; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 1 cp -r; sync"

Pour le parallèle :

rm -rf qqpart; mkdir qqpart; sync; res; cat qqch?/* > /dev/null; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 4 cp -r; sync"

On obtient 9.4 s pour le séquentiel et 8.2 s pour le parallèle.

Bref, je ne vois pas quoi faire d'autre pour argumenter mon propos. Mais si vous me sugerez d'autres tests, je les ferais avec plaisir.

En fait, l'écriture se fait à la fin en grande partie, lors du sync. Les écritures sont toutes bufferisés. C'est sur la lecture qu'il y a une optimisation possible, mais un bon choix du readahead résoud ce problème.

Donc tu veux des plus petits fichiers, ok. Je vais aussi me mettre en condition plus violentes, 4 cp séquentiels contre 4 cp parallèles. Donc 4 dossiers contenants chacun 100 MiB en fichier de 10 KiB.

mkdir qqch{1..4}
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch1/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch2/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch3/
dd if=/dev/urandom bs=1M count=100 | split -a 4 -b 10240 - qqch4/

La commande de test sera pour le séquentiel :

rm -rf qqpart; mkdir qqpart; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 1 cp -r; sync"

Et pour le parrallèle :

rm -rf qqpart; mkdir qqpart; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ qqch3/ qqpart/ qqch4/ qqpart | xargs -n 2 -P 4 cp -r; sync"

Et alors là les performances sont même contraire à que vous suggerez :

• Séquentielle : 4 min 38 s
• Parallèle : 3 min 23 s

Je le répète, pour moi, c'est le rôle du noyau d'optimiser ce genre de chose, pas de l'utilisateur. Encore faut-il avoir une machine bien configuré, et assez de RAM relativement à la taille des données qu'on manipule. C'est vrai, sur une machine limitée en mémoire, le noyau ne peut pas optimiser car il ne peut pas garder assez de pages sales en mémoire, mais ce n'est pas le cas général.

Pour moi le raisonnement est simple, je configure bien mon système par rapport à mon usage, je lui donne les moyens adéquats (assez de mémoire), et après c'est son problème, pas le mien. Toutes ces solutions (mise en file pour une copie séquentielles, etc.) ne sont à mes yeux que des solutions de contournement, et elle ne sont donc d'aucunes utilité quand il y a rien à contourner.

Bon alors testons.

Je prépare les données :

mkdir qqch1
mkdir qqch2
for((i=0;i<100;i++)); do dd if=/dev/urandom of=qqch1/$i bs=1M count=10; done
for((i=0;i<100;i++)); do dd if=/dev/urandom of=qqch2/$i bs=1M count=10; done

Je me prépare un alias, car je vais vider les caches pour chaque essai afin d'être dans des conditions équivalentes.

alias res="echo 3 > /proc/sys/vm/drop_caches"

Voici mes 4 commandes de test :

• séquentielle

  • avec sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 1 cp -r; sync"

  • sans sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 1 cp -r"

• parallèle

  • avec sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 2 cp -r; sync"

  • sans sync final

    rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 2 cp -r"

Bilan :

	Séquentielle	Parallèle
Avec sync final	59.4 s	59.3 s
Sans sync final	31.8 s	33.3 s

Bref, dans mon cas c'est le noyal qui s'occupe de bien faire comme il faut. Oui, les valeurs de dirty_ratio, dirty_expire_centisec, dirty_background_ratio… ne sont pas celles par défaut. Ce sont celles qui correspondent à mon usage.

Ça doit être moi qui ait du mal avec le concept. Je n'utilise pas de gestionnaire de fichier, je gère intégralement mes fichiers en ligne de commande, je n'utilise que des trucs comme mv, cp , rsync…

Utiliser un gestionnaire de copie me semble étrange, mais ça c'est mon opinion, et je conçois très bien qu'il peut être utile à certain. Par contre, utiliser un gestionnaire de copie via Wine, je pense que c'est clairement du masochisme.

Par contre l'argument de liberté de Supercopier, et le fait d'étudier le code est pour moi un argument pertinent.

Même si à titre personnel je juge toujours cette dépêche comme inutile, je comprends que certains la trouvent pertinente, c'est un progrès.

Dans l'ordre, je vais sur un site web :

Da Linux French Page

puis je choisis une dépèche,

Supercopier 3

puis je lis :

Le port pour Linux n'est pas d'actualité pour l'instant

Faîtes tourner les gens, ça à l'air bien comme substance pour ne pas s'embêter avec ce que certains nomment la cohérence.

Probablement :

   -c cipher_spec
          Selects the cipher specification for encrypting the session.

          Protocol version 1 allows specification of a  single  cipher.   The  sup‐
          ported values are ``3des'', ``blowfish'', and ``des''.  3des (triple-des)
          is an encrypt-decrypt-encrypt triple with three different  keys.   It  is
          believed  to be secure.  blowfish is a fast block cipher; it appears very
          secure and is much faster than 3des.  des is only supported  in  the  ssh
          client  for  interoperability with legacy protocol 1 implementations that
          do not support the 3des cipher.  Its use is strongly discouraged  due  to
          cryptographic weaknesses.  The default is ``3des''.

          For  protocol version 2, cipher_spec is a comma-separated list of ciphers
          listed in order of preference.  See the Ciphers keyword in  ssh_config(5)
          for more information.

Tu as essayé de rajouter un -c blowfish ?

Et en plus avec les id anonymes publiés tu peux vendre ton vote. Avec le scrutin papier actuel si tu vends ton vote l'acheteur ne peut que te faire confiance. Avec ce que tu proposes, la commercialisation des votes devient possible.

Les conditions de ton protocole experimental me semblent trop otimistes.

En vrac :

• Débit tellement important que ça risque de rendre le chiffrement limitant en vitesse, pas forcement représentatif du cas réel
• Pas de pertes de paquets
• Ping très faible, donc la latence introduite en faisant passer sur du TCP ne va pas être représentative

Bref, pour moi, avec ce protocole de mesure, tu va obtenir des différences qui seront faibles, mais en plus pas significative des différences observés lors d'un déploiement réel.

En passant par tun, ce système peut-il encore fonctionner ?

Tout à fait. Et niveau config, ne connaissant pas ta config exacte, les modifications à apporter me semblent mineure (même si au final ça change le niveau auquel est fait le tunnel, donc des modifications importantes).

du coup ça impliquerait (d'après ce que je me souviens) à une instance par client

Faudra que j'en parle à mon instance openvpn.

Serieusement, ça marche très bien avec une instance sur le serveur et n clients, avec n>1.

La question que je pose est la suivante : Veux tu faire passer autre chose que de l'IPv4 (genre IPv6) dans ton tunnel ?

Si la réponse est

• non : tu as le choix entre tap et tun sachant qu'il y a plus d'overhead avec tap, donc tun est préferable ;
• oui : tu dois choisir tap.

Tout à fait. Je savais exactement ce que je disais pour compulsivement.

Je considère que c'est lié à l'objet du site. Même si le contenu m'exaspère, s'il est intrinsèquement pertinent, je le note comme tel. Sinon je l'ignore.

Je reste dubitatif, il n'y a aucun raison d'avoir un controle d'integrité à ce niveau, et à mon avis, rien ne peut le justifier. Donc pour moi le VPN c'est en UDP sauf exceptions (comme passer un pare-feu à la con qui ne laisse passer que tcp {80,443}).

Par contre, as-tu une raison précise de faire du VPN au niveau de la couche transport (couche 2), et non au niveau de la couche réseau (couche 3). Tu peux en avoir, comme faire un VPN dual-stack IP-legacy et IP-v6, mais ça rajoute de l'overhead supplémentaire. À ta place je testerai d'abort avec tun au lieu de tap.

Je joue le jeu, très souvent sur le karma. Je déclare comme pertinent des contenus pertinents que je soit d'accord ou non, je déclare comme inutile des contenus inutiles, lorsque les sujets ont un rapport, même lointains avec l'objet du site.

Par contre tous les contenus sans rapport avec l'objet du site, au hasard :

• La politique (celle qui est sans rapport avec le libre)
• Les motos
• La couture de mamie (celle qui est sans rapport avec le libre)
• Les délires de SamWang
• Les sujets de société (ceux qui sont sans rapport avec le libre)

et bien là je joue le jeu certains jours, d'autres je plusssse et je moinsssse compulsivement. Si quelqu'un a envie d'aborder des sujets déconnectés de la thématique du site, je considère qu'il doit en assumer les conséquences (je ne dis pas qu'il doit pas le faire, mais qu'il savoir ce qu'il fait).

En l'occurrence, j'ai joué le jeu, et j'ai jugé ton propos selon sa pertinence, et pour moi il est inutile. Et vu la qualité des journaux que tu as posté ces derniers temps, j'ai l'espoir que tu atteigne un karma négatif. Pour éviter cela, peut-être, que tu proposera des contenus utiles.