Salut à tous !  
 
Bon cela fait un moment que je zieute sur le net des topics me permettant de répondre à cette question et je reste à ce jour toujours sans réponse !    
 
"Si les vitesse de lecture et d'écriture des SSD sont particulièrement sensible aux tailles des transfert de données, n'est-il pas plus logique de passer du conventionnel 4ko pour le M2 dédié à l'OS/Jeux principaux à un 512/1024ko ?"  
 
Je m'explique. Dans les différents bench SSD, on a tous pu remarquer je suppose, que selon la taille des données transféré même sur un NVME en PCI 4.0 on pouvait se retrouver facilement sur 200mo/s pour du 4ko alors que le disque peux monter mini à 5go/s (selon les modèles) sur des 1024 ko.
 
Je prend ici l'exemple du test de cowcotland : https://www.cowcotland.com/articles [...] -tous.html  
 
Donc niveau opti, est-ce que ce ne serais pas logique de passer le cluster du disque sur du 512 voir 1024 pour obtenir la performance max quitte à perdre une sacré dose d'espace sur le M2 ?
 
 
En vous remerciant d'avance à tous de votre réponse !

Bonjour
Non

Heuuu... une petite explication du pourquoi du comment ? xD

Parce que perdre de l'espace sur le disque ne vaut pas les "performances" que tu gagneras dans la plupart des utilisations que tu auras.
 
Pour réellement bénéficier des débits d'un Nvme il faut en avoir l'utilité, donc à moins de copier chaque jour des centaines de Go de données tu ne verras jamais la différence avec un SSD sata. Sans même parler du fait que tu seras bridé par le débit du disque le plus faible, donc si tu n'as pas du full Nvme 4.0 (avec la carte mère qui va bien) ça n'a aucune utilité hormis en bench.
 
Conclusion, si t'es prêt à sacrifier de l'espace disque pour des clous fonce, sinon utilise ton SSD normalement, sachant que même avec un Nvme 3.0 tu seras déjà très bien, c'est déjà surdimensionné pour une utilisation classique.

Je suis actuellement en train de rechercher sur mon PC le nombre de fichier d'une taille de - de 1024ko pour avoir une approximation de l'espace en plus que cette manip couterais sur une installe OS.
 
Je tiens quand même à préciser que si cette question m'est revenu en tête viens majoritairement du fait de la technologie RTX I/O qui est apparu chez NVIDIA et de la prise en charge de cette technologie pour les AMD (technologie HBCC) et DirectX 12 ultimate (Mars 2021, technologie DirectStorage).
 
Sachant que cette technologie permet au GPU de passer directement aux SSD sans passer par la case RAM (pour faire synthétique et absolument pas dans le détail).
 
Donc le fait de booster le SSD aux hormones permettrais également de gagner énormément de perfs en jeux.

Direct storage n'est pas encore aboutie et utilisée donc c'est un peu prématuré d'en parler comme si c'était acquis.
Après la techno servira sans doute à stocker les textures pour y accéder plus rapidement que sans le DS, mais pas sûr que les débits du nvme soient si importants pour la techno.  
J'ignore combien pèse une texture mais 200mo/s dans le pire des cas ça me parait déjà pas mal comme débit, c'est surtout pour les IOPS que le DS semble prometteur, mais je ne suis pas développeur donc ce n'est que théorique.
Eventuellement utiliser un SSD Nvme uniquement pour le DS une fois qu'il sera bien utilisé dans les jeux pourquoi pas.
 
Côté OS c'est en grande partie des fichiers de petite taille, donc le débit n'a vraiment pas d'intérêt dans ce cas, le système ne charge pas plus vite sur un Nvme que sur un Sata.

Entendu
 
Je vais lancer quelques tests sur deux M2 similaire pour vérif tout ça. Je ferais un retour détaillé sous un peu plus de 2 semaines (Actuellement en vacances xD) de ce que j'aurais pu en tirer. Faut également que je trouve un Jeu/Logiciel qui utilise le DirectStorage ou l'I/O.
 
Si tu as, ou quelqu'un d'autres des informations qui paraissent lié au sujet, hésite pas, j'en profiterais pour l'inclure dans le protocole de test tant qu'à faire

c'est pas uniquement les fichiers de moins de 1024ko qui vont être impactés,
dès que t'as un fichier dont le poids n'est pas un multiple de 1024, il va empiéter sur un autre cluster, et gâcher une grande partie de la place dispo.

ex: fichier de 1025 ko > ne tient pas sur un seul cluster de 1024ko > 2 clusters utilisés, le second pour seulement 1ko sur 1024ko dispo > prendra 2Mo pour à peine 1Mo et des poussieres

Effectivement j'avais zapé ce détail ><"
Je testerais déjà avec une install propre de win10 en 1024 et l'autre en 4 pour voir dans un premier temps l'espace bousillé ne serait-ce que pour l'install de base + drivers. (En gros les fichiers comportant le plus de taille minuscule)

par curiosité je suis en train de tester avec une clé usb de 120Go
 
je vais y mettre les dossiers Windows/Users et copier qqs jeux Steam,
 
en 4Ko vs en 1024ko

Tu aura des résultats dégeux à mon avis.. Ce qui va se passer c'est que tu va copier les cluster en format 4k (donc déjà étendu de base) sur une base de 1024 que tu va réétendre. Ce qui va te faire un coefficient d'augmentation de stockage encore plus monstrueux xD
 
Sans compter que tu fait le test sur un Disque qui n'est pas prévu pour du NTFS de base (prévu pour du exFat) et qui n'a pas non plus le fonctionnement hardware d'un SSD. Donc je pense que les résultats seront assez vague
 
Mais ça vaux toujours le coup de zieuter par curiositée ! (Et je t'avou que ne pouvant pas faire de tests actuellement je suis assez curieux du résultat xD)

a ce stade, la perte semble colossale...

sur la clé (120 Go), en 4ko
windows + program files + program files (x86) - 50.7Go

sur la même clé en 1024ko, j'ai tout simplement pas pu copier ces 3 dossiers,
ni même juste le dossier windows (25 Go devient... 200 Go)

(bcp de petits fichiers forcement...)

program files fait x2,5 de son coté,

.
.

là je teste avec des jeux

edit: pas aussi horrible,

Je ne suis pas sûr de comprendre ce que le test de HD tune fait exactement. Je n'ai pas trouvé de details.

Je ne vois pas comment l'outil fait pour changer la taille des clusters? pour un système de fichier donné, la taille d'un cluster reste fixe il me semblait.
Vous êtes sûr que ce test est relatif aux tailles de cluster et pas simplement à la taille de chaque commande sur une taille de cluster fixe?

Et bien si tu regarde sur la fenetre de logiciel il te demande la taille du fichier à tester. Donc je suppose que le reste qu'il teste viens bien du cluster ?

Est-ce que ça serait pas le hachage d'un fichier de 64MB en fichiers de xko qu'on observe sur cette image ?  

C'est ce que je pense également

Je remets une pièce dans la machine.
 
Et du RAID 0 avec des NVMe ?

Avec combien de disques ? 2 ou 10

Si le but est le DS et que tu as des vieux Nvme très faible en capacité pourquoi pas, tu peux faire un volume RAID 0 pour avoir une capacité plus importante, mais si c'est pour le côté perf ça n'a pas vraiment d'intérêt.  
Si c'est pour bencher à 10Go/s sur Crystal disk mark, ouais bon, voilà t'as tes 10Go/s, et après tu fais quoi ?
 
On est à environ 3Go/s en Nvme (en moyenne entre du 3.0 et 4.0), c'est peut-être déjà "trop" pour être un simple conteneur à textures, après je ne suis pas dév de jeux donc je me plante peut-être totalement, faudrait l'avis d'un gars un peu calé à ce niveau.
 
Mais ça n'a rien à voir avec le topic on est bien d'accord.

Non, les ssd ne sont pas "particulièrement sensible à la taille des fichiers".
Ils sont sensible à la taille réelle des données réelles mais beaucoup moins que les disques durs. En réalité ce qui compte c'est le nombre d'entrées/sorties, ou les temps d'accès. La vitesse en alleatiore sur petits fichiers n'est qu'une conséquence.  
 
Et 200Mo/s sur du 4k en aléatoire c'est énorme comparé à ce que fait un disque dur,  qui ne fera même pas 1Mo/s.
 
D'ailleurs avec un ssd, si tu accède à des données de 4k en sequenciel, tu approchera des perfs max du ssd.
 
Je ne suis pas allé vérifier la littérature mais à mon avis, quand tu vas augmenter la taille des clusters, tu ne vas rien accélérer du tout pour tes petits fichiers, tu auras toujours le même temps d'accès, ton petit fichier sera juste au milieu de plus de vide.
Si tu as un pauvre octet à lire dans ton cluster, que ce dernier soit petit ou grand, le temps d'accès restera le même. Ta vitesse de transfert sera de  1 octet divisé par le temps d'accès,  par exemple 1octet/0.05ms = 20 octets/millisecondes = 20Ko/secondes. Ce qui corresponds aussi au nombre d'E/S par secondes. Tu comprends bien que ton pauvre octet que tu transfère à 5Go/s, son temps de transfert est négligeable comparé au temps d'accès.
Les ssd peuvent faire plusieurs accès en parallèle pour améliorer la chose, mais ce qui accélerer l'utilisation du ssd ou de tout lecteur de masse, c'est que les logiciels fassent des lectures et écritures sur des gros paquets de données. Et ça, il n'y a que les devs des dits logiciels, et du système d'exploitation qui y peuvent un peut quelque-chose.

Je serais curieux de voir le test exécuté sur un ram drive.

Je pense que  grossir la taille des clusters peut quand même avoir un léger effet positif sur les performances mais uniquement sur les gros fichiers: cela devrai légèrement réduire la charge CPU et peut-être celle du contrôleur du SSD.