Re: J'ai du mal à comprendre

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.

Ça ne fait pas de mal que ton outil de copie le fasse. Personnellement une fois j'ai un peu à la va vite fait une copie d'un gros fichier sur une clef avant de partir pour me rendre compte pendant mon voyage (quand j'en avais besoin) que la copie c'était mal passé. C'est pas agréable.

D'ailleurs (je sais pas sur quoi tu fais tes backups) mais btrfs et zfs font eux aussi des checksum sur les (meta ?)données et au moins pour btrfs, il est capable de corriger les erreurs si le volume en question est en RAID autre que 0. Ce n'est pas parce que ta couche en dessous n'est pas fiable que tu ne peut pas par dessus ajouter de la fiabilité (comme en réseau) et c'est très agréable quand ton origine ou ta destination ne sont pas des périphériques branchés en IDE/SATA/SCSI.

Bref ça peut être utile.

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 ?

Comprends que c'est lié et quand tu rentre dans le lard de ton interlocuteur ça a plus tendance à le braquer.

J'ai une opinion, je l'exprime

Et c'est très bien ! (vraiment je parlais de la forme et pas du fond)

comme étant la mienne sans généraliser, il est vrai que je pourrais l'exprimer différement.

Tu n'a peut être pas tendance à généraliser mais tu donne vraiment l'impression de rabaisser les autres. Notamment dès le départ quand tu les met dans une jolie boite : ceux qui utilisent des gestionnaires de fichiers alors que toi tu fais de la CLI (alors que vcp et gcp entre autre montre que ce besoin est exprimé aussi par des utilisateurs de CLI).

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.

Si c'est tuner son noyau, mais il n'y a aucun mal si je connaissais cette technique je l'aurais probablement fais. Je n'ai absolument rien contre.
Par contre j'ai des questions sur ta technique.

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 ?

Au final, de ce que j'en comprend, si je fais un cp -R /etc /etc-back & cp -R /usr /usr-back le noyau va prendre le premier fichier de /etc le mettre en cache pour l'écriture ultérieur, puis il va prendre le second fichier de /etc ou le premier fichier de /usr le lire et mettre en cache pour son écriture. Ça n'est pas idiot. Un intérêt c'est que c'est indépendant de l'utilisateur. Mais je pense que c'est un peu pointu de faire ça via les le nombre ou le ratio de pages sales (il peut y avoir des implications auquel je ne pense pas). Ça devrait être dans une politique de lecture.

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.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)