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


13

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?


Quelle est l'application dans votre situation? Vous ignorez l'effet ou l'influence d'un contrôleur RAID et de son cache sur la configuration. Sur quel système d'exploitation vous concentrez-vous également? Quel système de fichiers envisagez-vous?
ewwhite

Pas d'application spécifique. J'utilise le logiciel raid1 depuis des années, mais je ne me penche jamais sur le problème que représentent les caches d'écriture. De plus, après avoir examiné les btrfs, pour lesquels il n'y a pas encore de fsck fiable, je me demande ce que je peux faire pour éviter la corruption, si je devais l'utiliser.
julianjm

1
Utilisez plutôt ZFS sur Linux et associez-le à un périphérique ZIL spécialement conçu. J'utilise le DDRDrive pour les systèmes ZFS :)
ewwhite

Utilisez-vous ZFS avec FUSE?
julianjm

2
Assurez-vous d'obtenir un UPS.
Michael Hampton

Réponses:


11

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 fichiers 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 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.


Je comprends que sous RAID matériel, c'est au contrôleur de faire la mise en cache (avec de la batterie, espérons-le), et il est conseillé de désactiver le cache des disques. Dans mon cas (je ne l'ai pas mentionné), j'utilise un raid logiciel. Il semble que le cache d'écriture n'est pas recommandé car cela entraînera une perte de données. Peut-être pas catastrophique (corruption du système de fichiers), mais une perte de données quand même. Je m'abstiendrai, pour le moment, de migrer mon softraid1 + ext4 vers btrfs + raid1. :)
julianjm

RAID n'aide pas à cela, car les données peuvent tout aussi bien se trouver dans les deux disques durs d'écriture que sur un disque dur.
psusi

@psusi Ce n'est pas une atténuation à 100%, mais il offre une protection supplémentaire . C'est un problème de timing. Les implémentations RAID individuelles diffèrent.
sysadmin1138

Ce n'est pas du tout une atténuation. Le lecteur secondaire n'a pas d'importance du tout, car en cas de panne, le primaire sera recopié sur le secondaire pour récupérer. Par conséquent, vous êtes de retour pour savoir si l'écriture a été effectuée sur le (premier) lecteur ou non.
psusi

3

À 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.


Je pense que les barrières vous protègent de la corruption des journaux (si le système de fichiers le demande), mais je ne suis pas sûr des données réelles sur les fichiers ... Émettre un vidage du cache après chaque écriture rendrait le cache d'écriture inutile, n'est-ce pas? ?
julianjm

@julianjm, bien sûr ... les données des fichiers mis en cache sont toujours perdues en cas de plantage, avec ou sans NCQ ou caches d'écriture de lecteur.
psusi
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.