jben a écrit 861 commentaires

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.

• Pour le tribunal de commerce
  Article L723-4 du code du commerce :

  Sont éligibles aux fonctions de juge d'un tribunal de commerce les personnes âgées de trente ans au moins :

  1° Inscrites sur la liste électorale dressée en application de l'article L. 713-7 dans le ressort du tribunal de commerce ou dans le ressort des tribunaux de commerce limitrophes ;
  […]
  5° Et qui justifient soit d'une immatriculation pendant les cinq dernières années au moins au registre du commerce et des sociétés, soit de l'exercice, pendant une durée totale cumulée de cinq ans, de l'une des qualités énumérées à l'article L. 713-8 ou de l'une des professions énumérées au d du 1° de l'article L. 713-7.

• Pour le conseil de prud-hommes :
  Article L1441-16 du code du travail :

  Sont éligibles, à condition d'avoir la nationalité française, d'être âgées de vingt et un ans au moins et de n'être l'objet d'aucune interdiction, déchéance, incapacité relative à leurs droits civiques :

  1° Les personnes inscrites sur les listes électorales prud'homales ;

  2° Les personnes remplissant les conditions requises pour y être inscrites ;

  3° Les personnes ayant été inscrites au moins une fois sur les listes électorales prud'homales, dès lors qu'elles ont cessé d'exercer l'activité au titre de laquelle elles ont été inscrites depuis moins de dix ans.

En bref, ce ne sont pas des juges professionnels. Des fois leurs décisions semblent surprenantes, mais dans ce cas, l'appel résout ce problème, puisqu'en appel, ce sont des juges professionnels.

Même en ayant lu la décision citée dans le journal, je n'émets aucun avis sur cette décision en particulier.

Edit : Le fait de chercher des références à mon propos implique que je réponde bien en retard après m'être fait, de multiples fois, doublé.

En tant qu'individu, les homo et hétéro sont égaux à la loi actuelle: "mariage entre un homme et une femme". Donc la question de l'égalité n'est pas la vrai raison. Il s'agit bien d'une extension du droit actuel.

Ça dépend comment tu pose la question.

• Les heterosexuels et les homosexuels homme et femme ont-il la même possiblilité respectivement de se marrier avec une femme et un homme ? La réponse est oui, on peut en conclure qu'ils ont les même droits.
• Les heterosexuels et les homosexuels ont-il la même possiblilité de se marrier avec la personne qu'ils désirent ? La réponse est non, on peut en déduire qu'ils n'ont pas les mêmes droits.

La manière de poser le problème biaise le raisonnement.

Et à mon avis, la manière de poser le problème tel qu'il est défini dans le premier point relève d'un argument spécieux.

(tu peut faire un pacs avec un cousin si je ne m'abuse).

"Un Pacs ne peut pas être conclu : (…) entre collatéraux jusqu'au 3eme degré (frères et sœurs, oncles et nièces, etc)"
"collatéraux : Frères, sœurs d'une personne et enfants de ces derniers (collatéraux privilégiés) ainsi qu'oncles, tantes, cousins, cousines (collatéraux ordinaires)."

C'est la où il y a une petite blague. Le comptage des degrés en droit civil n'est qu'un plus court chemin dans un graphe.

Donc des frères sont collatéraux au 2ᵉ degré, et des cousins germains sont collatéraux au 4ᵉ degré. Donc le PACS entre cousins germains est autorisé si je ne me trompe.

Exemple pour le comptage α a deux fils β et γ, qui ont chacun un fils respectivement δ et ε.

     ┏━━━┓
     ┃ α ┃
     ┗━┯━┛
  ┌────┴────┐
┏━┷━┓     ┏━┷━┓
┃ β ┃     ┃ γ ┃
┗━┯━┛     ┗━┯━┛
  │         │
┏━┷━┓     ┏━┷━┓
┃ δ ┃     ┃ ε ┃
┗━━━┛     ┗━━━┛

Donc β et son père α ont un degré de parenté de 1, β et γ qui sont frères ont un degré de parenté de 2, β et ε dont l'un est l'oncle de l'autre on un degré de parenté de 3, et enfin δ et ε qui sont cosins germains, ont un degré de parenté de 4.

J'ai bien compris. Mais je te dis que apt ne semble pas gerer le socks.

Je te propose une solution alternative consistant à installer un proxy http local sur la machine distante et à forwarder un port de la machine local vers le proxy http de la machine distante. Normalement cette solution devrait fonctionner. Ma réponse n'était qu'un HOWTO.

Je suis embeté, à la lecture de ce que tu écris, j'ai l'impression que le proxy socks local n'est pas utilisé.

Je ne trouve rien dans le man d'apt.conf sur Acquire::socks, apt-get sait-il vraiment utiliser un proxy socks ?

Je te propose d'utiliser tsocks (c'est un outils qui permet d'utiliser un proxy socks avec un programme qui n'est pas prévu pour, si ma mémoire est bonne, il utilise LD_PRELOAD pour charger le programme, et il intercepte les appels réseaux). Ça semble marcher avec apt-get.

Toutefois, si tsocks n'est pas installé sur ta machine, il va falloir trouver une autre solution. Voici ce que je te propose, soit comme solution transitoire avant tsocks, soit comme solution définitive.

1. Tu installe un proxy http sur la machine distante sur laquelle tu te connecte en ssh (au hasard squid qui utilise le port 3128 par defaut (quelle idée aussi d'utiliser le port 3128 pour un proxy socks… (oui j'aime les paranthèses imbriqués))). Prends garde à le configurer pour qu'il n'accepte de proxifier que ce qui vient de localhost, afin de ne pas en faire un relai pour le monde.
2. Tu transfere le port 3128 de ta machine local sur le port 3128 de ta machine distante au moyen d'un tunnel ssh ssh -L 3128:localhost:3128 -p 443 machinedistante.example.com
3. Tu configure apt pour qui l'utilise le proxy http sur localhost:3128 au moyen de Acquire::http::Proxy "http://localhost:3128" ou au moyen de la variable d'environnement http_proxy
4. Enjoy.