Ce serait intéressant de voir le point de vu de l'équipe de coreutils, ils peuvent peut être reporter certaines de tes optimisations ou options.
Je sais que récemment ils ont augmenté la taille du buffer de cp parce qu'un certain nombre de personnes avaient fait le même constat. En ce qui concerne les autres changements comme le multi-thread avec ring buffer ou l'écriture O_DIRECT, je pense que ça dénaturerait probablement la philosophie kiss de la commande ainsi que son comportement sachant que l'on parle d'une commande utilisée quotidiennement par un nombre incalculable de personnes.
lecture/écriture via le cache système
Je ne suis pas très clair sur ce que c'est. Pour moi le cache système est quelque chose de transparent. Le système mets en cache ce qu'il lit depuis le disque et le réutilise s'il en a besoin.
En effet, lors d'une lecture/écriture les données sont cachées en pages mémoire par le scheduler IO pour potentiellement s'économiser en cas de lecture ultérieure comme tu le décris. Or cette mise en cache est un goulot d'étranglement à ces débits, sur ma machine de test la mise en cache me limite à environ 2-3Go/s avec de la DDR5-5200 stock.
Le driver du fs a également un rôle non négligeable (j'ai des différences en bench entre du ext4 et du exfat à la faveur de ce dernier aussi étonnant que cela puisse paraître).
également multi-threadée
Ça c'est bien que sur NVMe si j'ai bien compris. Pour un disque SSD en SATA tu n'a pas de multiples queues utilisables pour lire/écrire. C'est le genre de choses avec les quelles un outils qui se destine à un usage généraliste doit pouvoir gérer (moi j'ai pas encore de NVMe
Dans le cas où la source et la destination sont sur le même périphérique, en effet bien qu'il me semble qu'il est possible de faire un semblant de multi-queues en SATA avec NCQ mais je ne connais assez mal ce protocole et de toute façon les SSDs performants ne sont plus SATA depuis longtemps.
Toutefois il faut bien en avoir de tête que beaucoup de copies se font entre 2 périphériques, ainsi paralléliser les 2 opérations est bien plus intéressant que de les séquentialiser et d'avoir un effet de montagnes russes, sous réserve que les vitesses de lecture et écriture soient à peu près similaires évidemment.
Dans tous les cas, qui peut le plus peut le moins mais il est vrai que pour du HDD plafonnant aujourd'hui à 300mo/s les outils historiques suffisent.
[^] # Re: alternative
Posté par Sapristi . En réponse à la dépêche Entrevue avec Herman BRULE, développeur d'Ultracopier et de CatchChallenger. Évalué à 1.
Je sais que récemment ils ont augmenté la taille du buffer de cp parce qu'un certain nombre de personnes avaient fait le même constat. En ce qui concerne les autres changements comme le multi-thread avec ring buffer ou l'écriture O_DIRECT, je pense que ça dénaturerait probablement la philosophie kiss de la commande ainsi que son comportement sachant que l'on parle d'une commande utilisée quotidiennement par un nombre incalculable de personnes.
En effet, lors d'une lecture/écriture les données sont cachées en pages mémoire par le scheduler IO pour potentiellement s'économiser en cas de lecture ultérieure comme tu le décris. Or cette mise en cache est un goulot d'étranglement à ces débits, sur ma machine de test la mise en cache me limite à environ 2-3Go/s avec de la DDR5-5200 stock.
Le driver du fs a également un rôle non négligeable (j'ai des différences en bench entre du ext4 et du exfat à la faveur de ce dernier aussi étonnant que cela puisse paraître).
Dans le cas où la source et la destination sont sur le même périphérique, en effet bien qu'il me semble qu'il est possible de faire un semblant de multi-queues en SATA avec NCQ mais je ne connais assez mal ce protocole et de toute façon les SSDs performants ne sont plus SATA depuis longtemps.
Toutefois il faut bien en avoir de tête que beaucoup de copies se font entre 2 périphériques, ainsi paralléliser les 2 opérations est bien plus intéressant que de les séquentialiser et d'avoir un effet de montagnes russes, sous réserve que les vitesses de lecture et écriture soient à peu près similaires évidemment.
Dans tous les cas, qui peut le plus peut le moins mais il est vrai que pour du HDD plafonnant aujourd'hui à 300mo/s les outils historiques suffisent.