Lancer des copies en parallèle n'a d'intérêt que si AIO le gère de manière optimale ce que mes tests avec fio n'ont pas démontré.
Par ailleurs, il faudrait que tu rajoutes iflag/oflag pour la lecture/écriture directe et bs pour la gestion du buffer qui doit être multiple de la taille de secteur de ton fs en lecture/écriture directe.
Dans l'absolu si on est uniquement sous linux avec un shell et les bonnes commandes, oui on doit pouvoir faire la même chose mais c'est long, peu mémorisable, avec une faible gestion des erreurs etc. D'où l'intérêt d'un utilitaire pour se simplifier la vie, par exemple elle permet aussi de copier une hiérarchie de dossier complète ainsi que de customiser la taille du ring buffer (qui est un multiple du buffer de lecture/écriture) pour compenser les différences de vitesse en lecture/écriture entre 2 périphériques.
Toutefois je ne cherche pas à convaincre qui ce soit, je m'attendais plutôt à des retours techniques de dev confrontés aux mêmes problématiques.
En effet je ne prétends pas qu'il s'agit d'un usage particulièrement courant mais au moins d'un usage existant.
Comme je disais plus haut, ça peut être de la copie sur un même périphérique ou entre 2 périphériques.
Pour le coup, je ne vois pas trop ce que fallocate() pourrait apporter. Je ne connaissais pas et n'ai pas testé sendfile() ni splice(), merci pour l'info, je bencherai ça dès que j'aurais le temps mais je ne m'attends pas à un gain significatif.
En ce qui concerne le ring buffer, l'idée n'est pas de remplacer les pages mémoires (qui ne sont pas un buffer mais un cache) mais de tricker AIO pour forcer à maximiser la taille des IO et les débiter immédiatement. D'ailleurs les 2 paramètres à savoir taille du buffer et lecture/écriture directe sont paramétrables complètrement indépendamment.
Tu élimine le cache de lecture via une écriture en directe ? J'imagine que c'est que le noyau tente de mettre en cache le fichier nouvellement créé.
Il y a un cache pour la source et un cache pour la destination, il est possible de désactiver l'un, l'autre ou les 2. Le noyau cache chaque donnée ayant été accédée qu'elle soit lue ou écrite.
J'ai pas l'impression que les périphériques amovibles soient encore tant utilisés (hors cas très ponctuel). Ceux qui s'achetaient des disques externes pour faire des sauvegardes ont l'air d'être passé au NAS.
Je pense que c'est un biais des milieux techniques, la large majorité des utilisateurs savent à peine ce qu'est un NAS.
Les fois où j'ai vu ce genre d'usages il y avait soit un NFS soit un autre protocole réseau impliqué.
La plupart du temps oui (mais pas toujours des fois c'est copié sur un périph froid en local pour libérer le stockage chaud puis dans un second temps synchronisé à distance), toutefois si ton NFS/LUN est hautement performant, ton périphérique local peut être le goulot d'étranglement.
Si c'est pour faire une petite copie local j'utilise généralement du CoW et j'ai pas de problème de performance.
Encore faut-il avoir un FS qui supporte le COW mais effectivement c'est une alternative certainement préférable.
> 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.
Quelle est la technique pour l'évier du coup ?
Écriture directe (O_DIRECT).
Toutefois il faut bien en avoir de tête que beaucoup de copies se font entre 2 périphériques
J'en suis pas particulièrement convaincu je t'avoue.
En usage particulier il y a par exemple le cas de ceux qui font des sauvegardes sur des disques externes, ou bien des transferts de gros fichiers type films/séries de SDD externe à SDD interne.
En usage professionnel il y a par exemple le transfert chaud/froid local (ex: duplication de VMs) sachant qu'il est courant de jongler entre plusieurs disques ou plusieurs raids. Pour information, ce dernier cas est celui qui a motivé le développement de l'outil avec un gain de temps environ x2-x3.
C'est dans les tuyaux ! J'ai prévu de le recetter de mon côté lorsque j'aurais du temps mais plusieurs inconvénients :
- API low level donc plus complexe à utiliser
- spécifique à Linux or je souhaite que mon utilitaire fonctionne également sous Windows
Par ailleurs, mon implémentation, user space donc, consomme déjà très peu de CPU donc je ne sais pas si l'usage d'une API kernel space permettra un gain significatif. En revanche je suis obligé d'utiliser des buffers assez importants pour rendre AIO efficace et j'ai l'espoir que io_uring permette de revenir à des tailles plus correctes.
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.
Après des années de lecture linuxfr en anonyme je finis par m'inscrire pour réagir à l'utilitaire Ultracopier.
Aujourd'hui avec la popularisation des SSD NVME qui lisent/écrivent actuellement entre 4go/s et 10go/s, la simple action de copie d'un fichier est devenue incroyablement inefficace avec les gestionnaires par défaut sous Linux et Windows et même les commands gnu de base :
- alternance de lecture/bufferisation puis écriture
- buffers trop faibles
- lecture/écriture via le cache système ce qui est une énorme limitation des débits gargantuesques que permettent les SSD actuels
Du coup j'en ai eu marre et ai développé une sorte d'alternative à la commande cp (les modos censurez moi si l'auto-promo est interdite) qui est également multi-threadée et avec la possibilité d'écriture directe pour ceux que ça intéresse : https://gitlab.com/Tulux/cpfast.
Personnellement je trouve ça très satisfaisant, en plus du gain de temps, de copier de gros fichiers aux limites de ce que permet le matériel que j'ai acheté. Sans l'avoir essayé je suppose que l'auteur d'Ultracopier a dû faire face au même constat et je serai bien curieux d'avoir un retour de sa part.
[^] # 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.
Lancer des copies en parallèle n'a d'intérêt que si AIO le gère de manière optimale ce que mes tests avec fio n'ont pas démontré.
Par ailleurs, il faudrait que tu rajoutes iflag/oflag pour la lecture/écriture directe et bs pour la gestion du buffer qui doit être multiple de la taille de secteur de ton fs en lecture/écriture directe.
Dans l'absolu si on est uniquement sous linux avec un shell et les bonnes commandes, oui on doit pouvoir faire la même chose mais c'est long, peu mémorisable, avec une faible gestion des erreurs etc. D'où l'intérêt d'un utilitaire pour se simplifier la vie, par exemple elle permet aussi de copier une hiérarchie de dossier complète ainsi que de customiser la taille du ring buffer (qui est un multiple du buffer de lecture/écriture) pour compenser les différences de vitesse en lecture/écriture entre 2 périphériques.
Toutefois je ne cherche pas à convaincre qui ce soit, je m'attendais plutôt à des retours techniques de dev confrontés aux mêmes problématiques.
[^] # 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.
Sinon VM != conteneur, j'adore les conteneurs mais ce n'est pas toujours utilisable pour tout.
[^] # Re: alternative
Posté par Sapristi . En réponse à la dépêche Entrevue avec Herman BRULE, développeur d'Ultracopier et de CatchChallenger. Évalué à 0.
En effet je ne prétends pas qu'il s'agit d'un usage particulièrement courant mais au moins d'un usage existant.
Comme je disais plus haut, ça peut être de la copie sur un même périphérique ou entre 2 périphériques.
Pour le coup, je ne vois pas trop ce que fallocate() pourrait apporter. Je ne connaissais pas et n'ai pas testé sendfile() ni splice(), merci pour l'info, je bencherai ça dès que j'aurais le temps mais je ne m'attends pas à un gain significatif.
En ce qui concerne le ring buffer, l'idée n'est pas de remplacer les pages mémoires (qui ne sont pas un buffer mais un cache) mais de tricker AIO pour forcer à maximiser la taille des IO et les débiter immédiatement. D'ailleurs les 2 paramètres à savoir taille du buffer et lecture/écriture directe sont paramétrables complètrement indépendamment.
[^] # Re: alternative
Posté par Sapristi . En réponse à la dépêche Entrevue avec Herman BRULE, développeur d'Ultracopier et de CatchChallenger. Évalué à 2.
Il y a un cache pour la source et un cache pour la destination, il est possible de désactiver l'un, l'autre ou les 2. Le noyau cache chaque donnée ayant été accédée qu'elle soit lue ou écrite.
Je pense que c'est un biais des milieux techniques, la large majorité des utilisateurs savent à peine ce qu'est un NAS.
La plupart du temps oui (mais pas toujours des fois c'est copié sur un périph froid en local pour libérer le stockage chaud puis dans un second temps synchronisé à distance), toutefois si ton NFS/LUN est hautement performant, ton périphérique local peut être le goulot d'étranglement.
Encore faut-il avoir un FS qui supporte le COW mais effectivement c'est une alternative certainement préférable.
[^] # 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.
De l'instanciation de VM à partir d'une même image par exemple, par ailleurs BTRFS/ZFS sont utilisés à la marge.
[^] # 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.
Écriture directe (O_DIRECT).
En usage particulier il y a par exemple le cas de ceux qui font des sauvegardes sur des disques externes, ou bien des transferts de gros fichiers type films/séries de SDD externe à SDD interne.
En usage professionnel il y a par exemple le transfert chaud/froid local (ex: duplication de VMs) sachant qu'il est courant de jongler entre plusieurs disques ou plusieurs raids. Pour information, ce dernier cas est celui qui a motivé le développement de l'outil avec un gain de temps environ x2-x3.
[^] # 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.
C'est dans les tuyaux ! J'ai prévu de le recetter de mon côté lorsque j'aurais du temps mais plusieurs inconvénients :
- API low level donc plus complexe à utiliser
- spécifique à Linux or je souhaite que mon utilitaire fonctionne également sous Windows
Par ailleurs, mon implémentation, user space donc, consomme déjà très peu de CPU donc je ne sais pas si l'usage d'une API kernel space permettra un gain significatif. En revanche je suis obligé d'utiliser des buffers assez importants pour rendre AIO efficace et j'ai l'espoir que io_uring permette de revenir à des tailles plus correctes.
[^] # 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.
# alternative
Posté par Sapristi . En réponse à la dépêche Entrevue avec Herman BRULE, développeur d'Ultracopier et de CatchChallenger. Évalué à 3.
Après des années de lecture linuxfr en anonyme je finis par m'inscrire pour réagir à l'utilitaire Ultracopier.
Aujourd'hui avec la popularisation des SSD NVME qui lisent/écrivent actuellement entre 4go/s et 10go/s, la simple action de copie d'un fichier est devenue incroyablement inefficace avec les gestionnaires par défaut sous Linux et Windows et même les commands gnu de base :
- alternance de lecture/bufferisation puis écriture
- buffers trop faibles
- lecture/écriture via le cache système ce qui est une énorme limitation des débits gargantuesques que permettent les SSD actuels
Du coup j'en ai eu marre et ai développé une sorte d'alternative à la commande cp (les modos censurez moi si l'auto-promo est interdite) qui est également multi-threadée et avec la possibilité d'écriture directe pour ceux que ça intéresse : https://gitlab.com/Tulux/cpfast.
Personnellement je trouve ça très satisfaisant, en plus du gain de temps, de copier de gros fichiers aux limites de ce que permet le matériel que j'ai acheté. Sans l'avoir essayé je suppose que l'auteur d'Ultracopier a dû faire face au même constat et je serai bien curieux d'avoir un retour de sa part.