Sinon, plus que la bande passante, ce qui va te gêner se sont le nombre d'IO.
Je trouve étonnant que personne n'a encore fait d'alim de PC avec batterie intégré histoire de garantir l'intégrité d'un "dernier fsync" avant de s'éteindre. Les cartes SAN fonctionnent ainsi, mais cela ne doit pas revenir si chère pour le faire sur un PC classique entier. Ainsi, on pourrait utiliser un fsycn() "réseau" un peu plus relâcher pour augmenter le nombre d'IO, puisque toutes data mis en RAM du serveur serait garanti d'être inscrite sur disque.
Un client qui fait vraiment de très très gros IO sur un cluster peut totalement l'écrouler et pour le moment il n'y a pas vraiment de parade. Si ce n'est de tuer le dit client.
Personne n'a encore écrit de scheduler "CFQ" pour le réseau ? Il n'y a rien la dessus dans les cgroup ?
[^] # Re: container compatible OCI ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Harbor 2.0. Évalué à 3.
Quel outil te génère tes 3 derniers sorties ?
Sinon, plus que la bande passante, ce qui va te gêner se sont le nombre d'IO.
Je trouve étonnant que personne n'a encore fait d'alim de PC avec batterie intégré histoire de garantir l'intégrité d'un "dernier fsync" avant de s'éteindre. Les cartes SAN fonctionnent ainsi, mais cela ne doit pas revenir si chère pour le faire sur un PC classique entier. Ainsi, on pourrait utiliser un fsycn() "réseau" un peu plus relâcher pour augmenter le nombre d'IO, puisque toutes data mis en RAM du serveur serait garanti d'être inscrite sur disque.
Personne n'a encore écrit de scheduler "CFQ" pour le réseau ? Il n'y a rien la dessus dans les cgroup ?
"La première sécurité est la liberté"