Sécurité du cache d'écriture sur les disques SATA avec barrières

J'ai lu récemment sur la mise en cache d'écriture, NCQ, les bogues du micrologiciel, les barrières, etc. concernant les disques SATA, et je ne sais pas quel est le meilleur paramètre qui sécuriserait mes données en cas de panne de courant.

D'après ce que je comprends, NCQ permet au lecteur de réorganiser les écritures pour optimiser les performances, tout en gardant le noyau informé des demandes qui ont été physiquement écrites.

Le cache d'écriture accélère le traitement d'une demande par le lecteur, car il n'attend pas que les données soient écrites sur le disque physique.

Je ne sais pas comment NCQ et le cache d'écriture se mélangent ici ...

Les systèmes de fichiers, spécialement ceux qui sont journalisés, doivent être sûrs quand une demande particulière a été écrite. De plus, le processus de l'espace utilisateur utilise fsync () pour forcer le vidage d'un fichier particulier. Cet appel à fsync () ne devrait pas retourner tant que le système de fichiers n'est pas sûr que les données sont écrites sur le disque.

Il y a une fonctionnalité (FUA, Force Unit Access), que je n'ai vue que sur les lecteurs SAS, qui force le lecteur à contourner le cache et à écrire directement sur le disque. Pour tout le reste, il y a des barrières en écriture, qui est un mécanisme fourni par le noyau qui peut déclencher un vidage du cache sur le lecteur. Cela force tout le cache à être écrit, pas seulement les données critiques, ralentissant ainsi tout le système en cas d'utilisation abusive, avec fsync () par exemple.

Et puis il y a des disques avec des bogues de firmware, ou qui mentent délibérément quand les données ont été physiquement écrites.

Cela dit, il existe plusieurs façons de configurer les lecteurs / systèmes de fichiers: A) NCQ et cache d'écriture désactivés B) Just NCQ activé C) Just Write cache activé D) NCQ et cache d'écriture activés

Je suppose que les barrières sont activées. BTW, comment vérifier si elles sont réellement activées?

En cas de coupure de courant, tout en écrivant activement sur le disque, je suppose que l'option B (NCQ, pas de cache) est sûre, à la fois pour le journal du système de fichiers et les données. Il peut y avoir une pénalité de performance.

L'option D (NCQ + cache), si vous utilisez des barrières ou FUA, serait sans danger pour le journal du système de fichiers et les applications qui utilisent fsync (). Ce serait mauvais pour les données qui attendaient dans le cache, et c'est au système de fichiers de les détecter (somme de contrôle), et au moins le système de fichiers ne sera pas (espérons-le) dans un état instable. En termes de performances, cela devrait être mieux.

Ma question, cependant, demeure ... Suis-je en train de manquer quelque chose? Y a-t-il une autre variable à prendre en compte? Existe-t-il un outil qui pourrait le confirmer et que mes lecteurs se comportent comme ils le devraient?

Pour les systèmes Enterprise, il existe une couche supplémentaire sous la forme d'un adaptateur de stockage (presque toujours une carte RAID) sur laquelle existe encore une autre couche de cache. Il y a beaucoup d'abstraction dans la pile de stockage de ces jours -ci , et je suis allé dans les détails en profondeur dans ce dans une série de blog j'ai fait savoir votre E / S .

Les cartes RAID peuvent contourner le cache sur disque, dont certaines permettent même de basculer cette fonctionnalité dans le BIOS RAID. C'est une des raisons pour lesquelles les disques Enterprise sont Enterprise, leur micrologiciel permet des choses telles que les disques grand public (en particulier les disques «verts») ne le permettent pas. Cette fonctionnalité répond directement au cas qui vous préoccupe: panne de courant avec des écritures non validées. Le cache de la carte RAID, qui doit être soit alimenté par batterie, soit sauvegardé par flash, sera conservé jusqu'à ce que le courant soit rétabli et que ces écritures puissent être recommencées.

Certains disques SSD d'entreprise incluent un condensateur intégré avec suffisamment de puissance pour valider le cache intégré avant la mise hors tension complète.

Si vous travaillez avec un système avec des disques directement connectés à la carte mère, il y a moins de garanties. À moins que les disques eux-mêmes n'aient la capacité de valider le cache d'écriture, une panne de courant entraînera en effet une perte. Le système de fichiers xfs a acquis une réputation de manque de fiabilité en raison de son incapacité à survivre uniquement à ce mode de défaillance; il a été conçu pour fonctionner sur des systèmes d'entreprise complets avec une capacité de survie de stockage conçue.

Cependant, le temps a avancé et XFS a été conçu pour y survivre. Les autres principaux systèmes de fichiers Linux (ainsi que les ntfs sous Windows) avaient déjà une ingénierie pour survivre à ce même mode d'échec. Comment cela est censé fonctionner, c'est que les écritures perdues n'apparaîtront pas dans le journal FS et qu'il saura qu'elles n'ont pas été commises, de sorte que la corruption sera détectée et contournée en toute sécurité.

Vous pointez le seul problème ici: le firmware du disque qui se trouve. Dans ce cas, le journal FS aura émis une hypothèse erronée par rapport à la réalité et la corruption peut ne pas être détectée pendant un certain temps. Le RAID de parité et le RAID miroir peuvent contourner ce problème car il devrait y avoir une autre copie validée à partir de laquelle extraire. Mais les configurations à disque unique n'auront pas cette contre-vérification, donc elles seront en fait défectueuses.

Vous contournez le risque de micrologiciel en utilisant des disques de qualité entreprise qui obtiennent beaucoup plus de validation (et sont testés par rapport à vos modèles de charge de travail présumés), et en concevant votre système de stockage afin qu'il puisse survivre à de telles contrevérités.

À l'origine, le journal du système de fichiers attendait la fin de l'écriture dans le journal avant d'émettre l'écriture dans les métadonnées, en supposant qu'il n'y avait pas de cache d'écriture de lecteur. Avec la mise en cache d'écriture de lecteur activée, cette hypothèse est rompue et peut entraîner une perte de données. Ainsi, des barrières ont été créées. Avec des barrières, le journal peut s'assurer que l'écriture dans le journal se termine avant l'écriture dans les métadonnées, même si le disque utilise la mise en cache d'écriture. Au niveau de la couche du pilote de disque, la barrière force un vidage du cache disque avant que les E / S suivantes ne soient envoyées, lorsque le lecteur signale qu'il a un cache d'écriture et qu'il est activé. Sinon, cela n'est pas nécessaire, de sorte que la barrière empêche simplement l'émission des E / S suivantes sur le variateur jusqu'à la fin des E / S précédentes. NCQ signifie simplement qu'il devra peut-être attendre plus d'une demande en attente pour terminer avant d'émettre plus.