Corrige-moi si je me trompe, mais ton test teste les accès aléatoires, avec des IO aléatoires, et donc tu testes le coût d'un accès aléatoire, alors que ce dont il est parlé est un fichier séquentiel mais dont données sont plus aléatoires dans le SSD du fait du COW (donc c'est peu de "random" d'une, car on n'a pas pour habitude de changer 100 000 fois un même fichier).
La, en imaginant la chose (donc aucun argument autre que ma tête), je me dis que ça n'a pas grand chose à voir avec ton test.
Peux-tu faire une démonstration avec par exemple la lecture séquentielle (et non randread, car on cherche l'impact du COW sur une lecture séquentielle) d'un fichier de 4 Go dont 100000 (au pif, mais 100000 changements aléatoires sur un fichier sans le réécrire complètement c'est déjà un cas d'usage peu classique voir avec une sacré marge) octets à la position aléatoires ont été modifié sur un FS supportant le COW (donc 100000x 4 KB ont été "déplacé"/fragmentés, soit 10%, amis si tu veux aller à l’extrême pourquoi pas change le 1000000x pour être, au hasard près, proche de 100%)?
(perso, je ne sais pas tester ça en moins de quelques minutes, mais suis intéressé par le résultat, par contre je sais que le randread a un impact surtout quand on n'a pas de queue mais rien de nouveau c'est testé partout lors d'un test d'un SSD; et je fantasme que lors d'un accès séquentiel sur un FS supportant le COW, le FS se ferait plaisir à détecter la demande séquentielle et ferait un autre thread qui lit en parallèle dans le cache les blocs arrivant sous peu mais déplacés, ou alors en fait le FS sait que le SSD s'en fout complet niveau perf, je ne sais pas juste suppositions)
Bref, ne faisons pas n'importe quel test au pif, mais un test qui correspond au cas d'usage débattu, et ton test ne semble pas être proche du cas débattu (ou je ne l'ai pas compris, c'est possible aussi, mais la je demande alors de m'expliquer en quoi ça correspond alors qu'il me semble qu'on met en jeu beaucoup de couches intermédiaires qui changent tout en disant que tel truc précis a un impact).
Tu me fais un calcul au dos de l'enveloppe ou une étude réelle ? Les SSD ne sont pas en sucre.
Non, mais mêmes les constructeurs n'osent pas dire qu'ils sont aussi endurant que les HDD, as-tu plus de connaissances sur le sujet que les constructeurs? Test d'endurance SSD (oui, ça meurt un SSD plus vite si on déplace les blocs plus souvent genre si on fait des déplacements en plus comme discuté, faut pas en faire 10000 trop souvent, nombre non pris au hasard)
Sérieusement, il y a assez eu de tests d'endurance sur les SSD et de discussions sur la quantité de blocs de réserve à mettre sur un SSD pour que ta réaction sarcastiquement sucrée sur ce sujet enlève de la crédibilité sur le reste qu'on connait moins.
[^] # Re: Fragmentation: encore un problème sur SSD?
Posté par Zenitram (site web personnel) . En réponse au journal [Btrfs et openSUSE] Épisode 0 : l’ex‐fs du futur. Évalué à 5. Dernière modification le 15 août 2017 à 14:44.
Corrige-moi si je me trompe, mais ton test teste les accès aléatoires, avec des IO aléatoires, et donc tu testes le coût d'un accès aléatoire, alors que ce dont il est parlé est un fichier séquentiel mais dont données sont plus aléatoires dans le SSD du fait du COW (donc c'est peu de "random" d'une, car on n'a pas pour habitude de changer 100 000 fois un même fichier).
La, en imaginant la chose (donc aucun argument autre que ma tête), je me dis que ça n'a pas grand chose à voir avec ton test.
Peux-tu faire une démonstration avec par exemple la lecture séquentielle (et non randread, car on cherche l'impact du COW sur une lecture séquentielle) d'un fichier de 4 Go dont 100000 (au pif, mais 100000 changements aléatoires sur un fichier sans le réécrire complètement c'est déjà un cas d'usage peu classique voir avec une sacré marge) octets à la position aléatoires ont été modifié sur un FS supportant le COW (donc 100000x 4 KB ont été "déplacé"/fragmentés, soit 10%, amis si tu veux aller à l’extrême pourquoi pas change le 1000000x pour être, au hasard près, proche de 100%)?
(perso, je ne sais pas tester ça en moins de quelques minutes, mais suis intéressé par le résultat, par contre je sais que le randread a un impact surtout quand on n'a pas de queue mais rien de nouveau c'est testé partout lors d'un test d'un SSD; et je fantasme que lors d'un accès séquentiel sur un FS supportant le COW, le FS se ferait plaisir à détecter la demande séquentielle et ferait un autre thread qui lit en parallèle dans le cache les blocs arrivant sous peu mais déplacés, ou alors en fait le FS sait que le SSD s'en fout complet niveau perf, je ne sais pas juste suppositions)
Bref, ne faisons pas n'importe quel test au pif, mais un test qui correspond au cas d'usage débattu, et ton test ne semble pas être proche du cas débattu (ou je ne l'ai pas compris, c'est possible aussi, mais la je demande alors de m'expliquer en quoi ça correspond alors qu'il me semble qu'on met en jeu beaucoup de couches intermédiaires qui changent tout en disant que tel truc précis a un impact).
Non, mais mêmes les constructeurs n'osent pas dire qu'ils sont aussi endurant que les HDD, as-tu plus de connaissances sur le sujet que les constructeurs?
Test d'endurance SSD (oui, ça meurt un SSD plus vite si on déplace les blocs plus souvent genre si on fait des déplacements en plus comme discuté, faut pas en faire 10000 trop souvent, nombre non pris au hasard)
Sérieusement, il y a assez eu de tests d'endurance sur les SSD et de discussions sur la quantité de blocs de réserve à mettre sur un SSD pour que ta réaction sarcastiquement sucrée sur ce sujet enlève de la crédibilité sur le reste qu'on connait moins.