Bonjour,
 
Dans toutes les documentations de tgt (cible iSCSI sous Linux), je trouve la ligne suivante dans /etc/tgt/targets.conf

 
excepté ici
http://samcaldwell.net/index.php/t [...] nux-rhel-6
 
où on lit simplement
#  In the test case for this article, write-cache was turned on.  However, there are many other
#  cases where turning write-cache off may be appropriate, such as shared storage.
 
J'ai fait des essais avec Crystal Disk Mark sur l'initiateur (serveur virtuel sous Windows) : j'obtiens une belle amélioration des performances écriture aléatoire en activant cette option (allant de x1.5 à x10 selon la taille de la file).
 
D'ailleurs, c'est l'option par défaut : en l'absence de directive contraire, tgt active le cache en écriture.
 
A un autre niveau, le mode "Write Back" du contrôleur RAID matériel est déjà activé. Mais il dispose d'une protection locale par batterie, lui...
 

• Quel est votre avis sur la question ?
• Dois-je activer cette option sur un serveur de fichiers en production ?
• Pourquoi peut-il être plus adapté de mettre "write-cache off" pour du stockage partagé ?
• Que se passe-t-il en cas de rupture de l'alimentation électrique ? (sachant que cela arrive parfois, et que les serveurs ne savent pas s'éteindre correctement lorsque les onduleurs arrivent en fin de capacité)

Merci !
 
 

Je pense que t'es pas le seul à chercher http://forum.pcinpact.com/topic/16 [...] rgetsconf/

Si, mais à plusieurs endroits à la fois !

Salut,
 
Au niveau de la "sécurité" des données, activer write-cache au niveau de la target iSCSI, c'est le même principe qu'activer write-cache sur le contrôleur RAID sans avoir de batterie/flash. En cas de panne de courant ou plantage, tu perdras les modifications qui n'ont pas encore été envoyées au contrôleur RAID.
 
Personnellement, je n'active pas le write-cache sur mes targets iSCSI software.
 
A+

En y réfléchissant à tête reposée, la bonne gestion du scénario "panne de courant" me parait être un prérequis indispensable au write-cache niveau serveur.
 
Je vais donc opter pour plus de sécurité au détriment des performances en aléatoire.
 
Merci pour la réponse (et pour les lectures)