Sous Linux (et pas seulement, Windows aussi même si ça a l’air moins bien géré historiquement), la RAM disponible sert de cache en écriture, et on peut régler le comportement (pourcentage de la mémoire utilisé pour la rétention, durée de rétention, pourcentage à atteindre pour commencer à écrire, etc).

Mais vu qu’ici il s’agit d’écrire de grandes quantités de données sur disque (on parle de 100 Go et nettement plus), il faudrait de grosses quantités de RAM, donc à voir côté budget et même avant cela pour la simple faisabilité technique (taille max d’une barrette de RAM et nombre d’emplacements sur la carte mère).

(quote:57441:brice.wernet)
Effectivement, le cache en écriture est actif même sous Windows 10!

Oui et même avant la version 10.

Mais il est vachement limité: chez moi il ne monte pas en cas d’écritures aléatoires: on voit qu’il monte puis il s’arrête et là ça ralenti.

Je ne sais pas dans quelle mesure ce cache est réglable dans son fonctionnement, mais pas beaucoup il me semble. Il faut dire que Windows est à la base un OS “desktop” et pas fait pour gérer des applications de type serveur.

Il faudrait un cache un peu moins stupide, qui aggrège les écritures ensemble, les réorganise.

C’est ce que font depuis quasiment le début certains I/O schedulers (ordonnanceurs d’E/S) de Linux, d’ailleurs tu peux choisir celui que tu utilises, au boot je crois, et il y a régulièrement des tests comparatifs. Avec les SSD qui ont pris une place importante, les ordonnanceurs orientés disques magnétiques, qui cherchaient à optimiser en fonction de la géométrie des disques, sont délaissés au profit d’ordonnanceurs qui ne font rien (pas besoin avec un SSD et ses temps d’accès quasi nuls).

Un peu comme les cartes contrôleurs RAID haut de gamme, qui réarrangent le cache pour ne pas écrire deux fois au même endroit, écrire tout en même temps, se caler sur les tailles d’échange des pistes pour déplacer au minimum les têtes au lieu de réécrire plusieurs fois les mêmes endroits

C’est ce que tentent de faire au mieux les ordonnanceurs dont je parle juste avant :-) .

(quote:57518:brice.wernet)
Windows 2000, option “partage de fichier”, petite case à cocher “optimiser”: 256Mo réservés pour l’OS et les applis, tout le reste pour le cache :) Il fallait savoir où décocher cette fichue option pour récupérer sa RAM :)

Oui mais ça reste un cache sur lequel on n’a aucun contrôle particulier, contrairement à Linux (et Unix et les BSD sauf erreur de ma part).

Sauf que si on ordonnance les écritures, on évite d’écrire dix fois les mêmes cellules (il me semble qu’on ne peut pas écrire moins de 128Ko sur un SSD, mais nos OS sont en blocs de 4k.

Il faudrait faire une petite simulation mais de toutes façons à partir du moment où les écritures ne sont pas linéaires, effectivement les SSD écrivent à coup de ~128 k, et je ne pense pas que les ordonnanceurs qui peuvent regrouper des écritures voisines servent à quelque chose (pas aux performances en tous cas, ce qui est déjà un signe).

Les cartes contrôleurs je ne sais pas, mais les SAN, c’est souvent du I5 avec un Linux bien paramétré par IBM

Effectivement les baies SAN un peu évoluées (IBM ou autre, EMC étant une des marques les plus connues) bénéficient d’un travail sur le sujet. J’ai pu constater vers 2014 en production qu’une de ces baies EMC un peu onéreuses, équipées de plein de disques magnétiques, tenait une belle charge en terme d’accès concurrents.

patos a dit:

Dès l’or, l’écriture

Joli ce “dès l’or”

est en attente en cache SSD de présence d’écriture voisine. Au bout de quelques secondes, elle devient purgée de toutes façons.

Oui on peut supposer que le SSD fait son maximum pour éviter d’écrire trop tôt, en utilisant un peu de RAM ; cela dit je ne suis pas sûr que beaucoup de modèles sont concernés, car il faut que le SSD intègre un condensateur assez important pour garantir l’écriture en cas de coupure de courant (pas forcément un gros condo mais il faut aussi que le firmware gère ça). Après, ça ne sert à rien au SSD d’avoir beaucoup de RAM, il suffit d’en avoir assez pour quelques blocs de 128 k ; dont pour les raisons que tu as mentionnées de fonctionnement de filesystem.

• Logiciellement, sur un système de fichiers à allocation lors de l’écriture, on n’écrit pas l’ancien bloc: on en alloue un nouveau. Du coup, on n’use pas la cellule qui contient la donnée mais une autre. Par ce biais, on peut obtenir des données plus fragmentées, avec des blocs systèmes de fichiers plus petits que les blocs minimaux d’écriture du SSD, sans lui péter son usure pour autant.

Ben vu qu’on écrit les données de toutes façons (que ce soit en place ou sur un nouveau bloc alloué, effectivement ce 2e cas avec les FS journalisés), on use tout autant le SSD me semble.