FR3023030B1 - Zone de donnees d'invalidation pour cache - Google Patents

Zone de donnees d'invalidation pour cache Download PDF

Info

Publication number
FR3023030B1
FR3023030B1 FR1555325A FR1555325A FR3023030B1 FR 3023030 B1 FR3023030 B1 FR 3023030B1 FR 1555325 A FR1555325 A FR 1555325A FR 1555325 A FR1555325 A FR 1555325A FR 3023030 B1 FR3023030 B1 FR 3023030B1
Authority
FR
France
Prior art keywords
log
cache
block
invalidation
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
FR1555325A
Other languages
English (en)
Other versions
FR3023030A1 (fr
Inventor
Pulkit Misra
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Western Digital Technologies Inc
Original Assignee
HGST Netherlands BV
Western Digital Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by HGST Netherlands BV, Western Digital Technologies Inc filed Critical HGST Netherlands BV
Publication of FR3023030A1 publication Critical patent/FR3023030A1/fr
Application granted granted Critical
Publication of FR3023030B1 publication Critical patent/FR3023030B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0871—Allocation or management of cache space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0891—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using clearing, invalidating or resetting means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1024—Latency reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1041—Resource optimization
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62—Details of cache specific to multiprocessor cache arrangements

Abstract

La présente invention concerne des caches, des procédés et des systèmes pour utiliser une zone de données d'invalidation. Le cache peut comprendre un journal configuré pour suivre des blocs de données, et une zone de données d'invalidation configurée pour suivre des blocs de données invalidés associés aux blocs de données suivis dans le journal. La zone de données d'invalidation peut se situer dans une région de cache distincte du journal. Le procédé pour invalider un bloc de cache peut comprendre de déterminer un bloc de journal suivant une adresse de mémoire associée à une opération d'écriture reçue. Le procédé peut également comprendre de déterminer un bloc de journal mappé sur la base du bloc de journal et d'un enregistrement d'invalidation. Le procédé peut également comprendre de déterminer si des opérations d'écriture sont en suspens. Si tel est le cas, le procédé peut comprendre d'agréger les opérations d'écriture en suspens et d'exécuter une seule opération d'écriture sur la base des opérations d'écriture agrégées.

Description

ZONE DE DONNEES D’INVALIDATION POUR CACHE
CONTEXTE
Domaine de l’invention
La présente invention concerne des systèmes et des procédés de mise en cache, et est plus particulièrement destinée à fournir une région pour traiter des données invalidées pour un cache.
Contexte
Un cache peut généralement être utilisé pour accélérer les accès lors de la lecture ou de l’écriture de données au niveau d’un stockage sous-jacent, tel qu’une mémoire flash ou un disque dur. A réception d’une opération d’écriture depuis un hôte, le cache peut mettre à jour un bloc de données stocké afin de déterminer si le bloc de données a changé (par exemple, si le bloc de données est valide ou non valide). Parfois, le cache peut écrire les nouvelles données de l’opération d’écriture à une autre entrée dans le cache, et reporter l’éviction ou la suppression de l’ancienne entrée de cache. Ceci est dû au fait que l’éviction ou la suppression de l’ancienne entrée de cache peuvent entraîner des baisses de performance tandis que le cache attend que le stockage sous-jacent soit mis à jour. L’utilisation de ce report permet au cache de terminer le traitement de l’opération d’écriture et de rendre le contrôle plus tôt à l’hôte. RÉSUMÉ
Les modes de réalisation de la présente invention se rapportent à des caches, des procédés et des systèmes pour utiliser une zone de données d’invalidation.
Dans un mode de réalisation, la présente divulgation se rapporte à un cache. Le cache peut inclure un journal et une zone de données d’invalidation. Le journal peut être configuré pour suivre des blocs de données stockés dans la mémoire cache. Là zone de données d’invalidation peut être configurée pour suivre des blocs de données invalidés associés aux blocs de données suivis dans le journal, la zone de données d’invalidation se situant dans une région séparée de la mémoire cache par rapport au journal.
Dans un mode de réalisation, la présente invention concerne un procédé pour invalider un bloc dans une mémoire cache. Le procédé peut comprendre de déterminer un bloc de journal suivant une adresse de mémoire associée à une opération d’écriture reçue, le bloc de journal étant stocké dans un journal de la mémoire cache. Le procédé peut également comprendre de déterminer un bloc de journal mappé sur la base du bloc de journal déterminé et en outre basé sur un enregistrement d’invalidation, le bloc de journal mappé et l’enregistrement d’invalidation étant stockés dans une zone de données d’invalidation du cache. Le procédé peut également comprendre de déterminer si des opérations d’écriture sont en suspens. Si des opérations d’écriture sont en suspens, le procédé peut comprendre d’agréger les opérations d’écriture en suspens et d’effectuer une seule opération d’écriture sur la base des opérations d’écriture agrégées. Si aucune opération d’écriture n’est en suspens, le procédé peut comprendre d’exécuter l’opération d’écriture reçue.
Dans un mode de réalisation, la présente invention concerne un procédé de récupération d’un cache. Le procédé peut comprendre de déterminer une reconstruction initiale de la mémoire cache sur la base d’un journal de la mémoire cache. Pour chaque bloc de journal mappé dans un enregistrement d’invalidation dans une zone de données d’invalidation de la mémoire cache, le procédé peut comprendre de déterminer si un bloc de données correspondant suivi dans le journal est valide, sur la base du bloc de journal mappé. Si le bloc de données correspondant est déterminé comme n’étant pas valide, le procédé peut comprendre l’éviction du bloc de données correspondant de la reconstruction initiale de la mémoire cache.
Les modes de réalisation décrits dans la présente peuvent comprendre des aspects supplémentaires. Par exemple, le journal peut être configuré pour suivre des métadonnées pour les blocs de données, les métadonnées pouvant comprendre une adresse de mémoire correspondant au bloc de données, et la zone de données d’invalidation peut être configurée pour suivre des métadonnées associées aux blocs de données invalidés, les métadonnées associées pouvant inclure une adresse de mémoire correspondant au bloc de données invalidé. Le journal peut être configuré pour suivre les blocs de données en utilisant des blocs de journal, les blocs de journal pouvant être configurés pour stocker les métadonnées pour les blocs de données, et la zone de données d’invalidation peut être configurée pour le suivi des métadonnées associées aux blocs de données non valides au moyen d’enregistrements d’invalidation et de blocs de journal mappés, les blocs de journal mappés pouvant être configurés pour stocker les métadonnées associées aux blocs de données non valides, et les enregistrements d’invalidation pouvant être configurés pour stocker les blocs de journal mappés. Les métadonnées suivies dans le journal peuvent en outre comprendre un index dans un ensemble de métadonnées stockées dans chaque bloc de journal, et les métadonnées suivies dans la zone de données d’invalidation peuvent en outre comprendre un index dans un ensemble de métadonnées stockées dans chaque bloc de journal mappé. Le cache peut être configuré pour déterminer un numéro d’enregistrement d’invalidation associé à un enregistrement d’invalidation dans la zone de données d’invalidation sur la base d’un numéro de bloc de journal correspondant associé à un bloc de journal. Le cache peut être configuré pour déterminer un numéro de bloc de journal mappé associé à un bloc de journal mappé dans la zone d’invalidation sur la base d’un numéro de bloc correspondant de journal associé à un bloc de journal. L’index suivi dans le journal peut être sélectionné pour avoir la même valeur que l’index suivi dans la zone de données d’invalidation. L’adresse de mémoire suivie dans la zone de données d’invalidation peut être tronquée par rapport à l’adresse de mémoire suivie dans le journal, et la troncature peut être déterminée sur la base d’une taille de stockage d’un dispositif de stockage sous-jacent étant placé en cache ou sur un décalage déterminé sur la base d’une adresse de mémoire d’un bloc dans le dispositif de stockage sous-jacent. Déterminer le bloc de journal mappé peut inclure de déterminer un numéro de bloc de journal mappé pour le bloc de journal mappé en déterminant un numéro d’enregistrement d’invalidation en divisant un numéro de bloc de journal associé au bloc de journal déterminé par une capacité de l’enregistrement d’invalidation dans la zone de données d’invalidation et en calculant une fonction de plafonnement du résultat de la division, le numéro d’enregistrement d’invalidation identifiant l’enregistrement d’invalidation, et en déterminant le numéro de bloc de journal mappé en calculant une opération modulo du numéro de bloc de journal avec la capacité de l’enregistrement d’invalidation. Déterminer si des opérations d’écriture sont en suspens peut comprendre de récupérer un champ d’une structure de données en mémoire RAM correspondant à l’enregistrement d’invalidation. Agréger les opérations d’écriture en suspens peut inclure de placer en file d’attente les opérations d’écriture suivantes, d’identifier les opérations d’écriture qui opèrent sur le même bloc de données, et de déterminer la seule opération d’écriture sur la base des opérations d’écriture qui opèrent sur le même bloc de données. La zone de données d’invalidation peut être une région séparée de la mémoire cache par rapport au journal. Le cache peut être un cache de proximité de contenu, et le journal peut suivre au moins un des blocs de données associés et des blocs de données indépendants dans le cache de proximité de contenu. Déterminer la reconstruction initiale peut inclure la récupération de blocs de données et de métadonnées décrivant les blocs de données, les blocs de données récupérés et les métadonnées étant récupérés à partir du journal. Déterminer si le bloc de données correspondant suivi dans le journal est valide peut comprendre de comparer des métadonnées décrivant le bloc de données correspondant suivi dans le journal à des métadonnées décrivant le bloc de données correspondant suivi dans le bloc de journal mappé. Comparer les métadonnées peut comprendre de comparer une première adresse de mémoire et un premier index pour le bloc de données correspondant suivi dans le journal à une seconde mémoire et un second index suivi dans le bloc de journal mappé.
BREVE DESCRIPTION DES FIGURES
Divers objets, caractéristiques et avantages de la présente divulgation peuvent être mieux appréciés en référence à la description détaillée qui suit, considérée en lien avec les dessins qui suivent, dans lesquels des numéros de référence identiques identifient des éléments identiques. Les dessins qui suivent ont uniquement un but d’illustration et ne sont pas destinés à limiter l’invention, dont la portée est définie dans les revendications qui suivent.
La figure 1 illustre un exemple de système comprenant une mémoire cache, conformément à certains modes de réalisation de la présente invention.
Les figures 2A-2B illustrent des exemples de schémas de principe d’une mémoire cache, conformément à certains modes de réalisation de la présente invention.
Les figures 3A-3B illustrent des exemples de mappages entre un journal et une zone de données d’invalidation, conformément à certains modes de réalisation de la présente invention.
La figure 4 illustre un exemple de procédé d’invalidation utilisant la zone de données d’invalidation, conformément à certains modes de réalisation de la présente divulgation.
La figure 5 illustre un exemple de procédé de récupération de la mémoire cache, conformément à certains modes de réalisation de la présente divulgation.
DESCRIPTION DÉTAILLÉE
La présente divulgation concerne des systèmes et des procédés d’utilisation d’une zone de données d’invalidation pour un cache. Dans certains modes de réalisation, le cache peut inclure une zone de journal et une zone de données d’invalidation. La zone de journal peut être un journal de consignation pour suivre les mises à jour de la mémoire cache et les opérations de la mémoire cache de manière persistante, en cas de besoin de récupération de la mémoire cache. La zone de données d’invalidation peut stocker des enregistrements d’invalidation pour les blocs de cache qui sont enlevés ou évincés du cache. La zone de données d’invalidation peut généralement suivre les informations concernant les blocs de données mis en mémoire cache qui ont été invalidés, par exemple lorsque la mise en mémoire cache est en pause ou, sinon, interrompue. La zone de données d’invalidation peut accompagner la zone de journal et occuper une région séparée de la mémoire cache. En outre, certains modes de réalisation de la zone de données d’invalidation peuvent stocker un sous-ensemble de métadonnées qui correspond à un ensemble complet de métadonnées généralement stocké dans le journal.
La figure 1 illustre un exemple de système 100, comprenant une mémoire cache 104, conformément à certains modes de réalisation de la présente divulgation. Le système 100 comprend un hôte 102, un cache 104, et un stockage 106a-106c. L’hôte 102 transmet des demandes lecture et d’écriture au cache 104. Le cache 104 traite les demandes de lecture et d’écriture de données vers et depuis le stockage sous-jacent 106a-106c. Par exemple, pour traiter une demande de lecture, le cache 104 peut déterminer si des données correspondant à une adresse de mémoire demandée sont stockées dans le cache. Si l’adresse de mémoire demandée est mise en cache, cette situation peut parfois être considérée comme un « succès de lecture ». Si l’adresse de mémoire demandée n’est pas mise en cache, cette situation peut être considérée comme un « échec de lecture ». Après un succès de lecture, le cache 104 peut retourner les données demandées plus rapidement directement depuis le cache 104. En revanche, lors d’un « échec de lecture », le cache 104 peut lire les données demandées à partir du stockage plus lent 106a-106c.
De même, pour traiter une demande d’écriture, le cache 104 peut déterminer si une adresse de mémoire demandée est déjà stockée dans le cache. Si l’adresse de mémoire demandée est mise en cache, cette situation peut parfois être considérée comme un « succès d’écriture ». Si l’adresse de mémoire demandée n’est pas mise en cache, cette situation peut être considérée comme un « échec d’écriture ».
La figure 2A illustre un exemple de schéma de principe de cache 104, conformément à certains modes de réalisation de la présente invention. Dans certains modes de réalisation, le cache 104 peut comprendre un superbloc 202, une zone de données de référence 204, un journal 206, une zone de données d’invalidation 208, et une zone de démarrage à chaud 210. Le journal 206 peut inclure des blocs de journal 212. Les blocs de journal 212 peuvent inclure des métadonnées 214 et des données 216.
Le cache 104 peut utiliser une approche basée sur le journal pour apporter la persistance, de sorte que le cache 104 puisse être récupéré en cas de besoin. Certains modes de réalisation du journal 206 peuvent être subdivisés en blocs de journal 212. Par exemple, des blocs de journal 212 peuvent avoir une taille d’environ 256 Ko. D’autres tailles peuvent également être utilisées en relation avec la taille totale du cache 104. Si un bloc de journal 212 a une taille d’environ 256 Ko, les métadonnées 214 peuvent occuper jusqu’à environ 4 Ko d’espace et les données 216 peuvent utiliser environ 252 Ko d’espace. Comme avant, d’autres tailles peuvent également être utilisées en fonction des besoins du journal 206 et du cache 104.
Les données 216 peuvent inclure le contenu associé à un bloc de cache qui est suivi dans le journal 206. Des exemples de métadonnées 214 peuvent inclure une adresse de mémoire (par exemple, une adresse de bloc logique (LBA)), un type de bloc de cache, un décalage, et une valeur de hachage pour la correction d’erreur. Un exemple de type de bloc de cache peut inclure le suivi qu’un bloc de cache est un bloc indépendant ou un bloc associé. Un bloc indépendant et/ou un bloc associé peuvent être utilisés avec un cache de proximité de contenu. Dans certains modes de réalisation, le cache 104 peut effectuer une mise en mémoire cache sur la base de la similitude du contenu d’un bloc de cache (proximité du contenu). Un bloc associé peut suivre les modifications, ou différences, entre les blocs de référence de base. Cette mise en cache de contenu de proximité peut en outre permettre de déterminer quand un bloc de cache a été utilisé pour la dernière fois (proximité temporelle) ou d’identifier des blocs de cache avec des adresses de mémoire similaires (proximité spatiale). Un bloc indépendant peut être un bloc placé en mémoire cache sur la base d’une proximité temporelle et/ou d’une proximité spatiale, mais non d’une proximité de contenu. Le décalage peut identifier un bloc de mémoire spécifique d’intérêt ou un emplacement de mémoire spécifique d’intérêt à l’intérieur d’un bloc de mémoire. Par exemple, le décalage peut être similaire à un pointeur dans les données 216 qui se réfère à des données spécifiques d’intérêt.
Du fait que les métadonnées 214 et les données 216 peuvent être combinées en un seul bloc de journal 212, des écritures de journal peuvent se produire en flots ou en lots, et les écritures de données et de métadonnées peuvent être combinées en une seule opération d’écriture. Le stockage d’à la fois des métadonnées 214 et des données 216 dans un seul bloc de journal 212 peut ainsi fournir une réduction d’environ 50 % des opérations d’écriture par rapport à avoir à écrire les métadonnées 214 et les données 216 séparément, à des endroits différents.
Dans certains modes de réalisation, le journal 206 peut être un journal circulaire. C’est-à-dire que le cache 104 peut écrire dans le journal 206, généralement séquentiellement, et lors que la fin du journal 206 est atteinte, l’opération d’écriture suivante peut retourner à un point de départ pour commencer le cycle suivant. Des métadonnées et des données correspondant à des succès d’écriture sur des données mises en cache peuvent être écrites dans un nouveau bloc de journal 212 dans le journal 206. Des écritures séquentielles peuvent permettre d’éviter d’avoir sinon besoin de lire les métadonnées 214 stockées dans chaque bloc de journal 212. Cependant, le support d’écritures séquentielles peut également signifier que le journal 206 peut comprendre plusieurs blocs de journal 212 qui correspondent au même bloc de mémoire cache. Par exemple, une première écriture à l’adresse de mémoire 8 pourrait être suivie dans le bloc de journal 1. Une écriture suivante à la même adresse de mémoire, l’adresse de mémoire 8, pourrait être suivie dans le bloc de journal 3 (par exemple si le cache 104 traitait des mises à jour de blocs de cache d’intervention qui utilisaient le bloc de journal 2). Même si les blocs de journal 1 et 2 suivent également des métadonnées et des données correspondant à l’adresse de mémoire 8, le cache 104 peut économiser le temps de traitement pour les blocs de journal existants. Au lieu de cela, la conception du journal 206 permet au cache 104 d’écrire l’entrée pour le bloc de journal 3 directement dans le journal 206 sans avoir à lire des métadonnées supplémentaires. Par conséquent, la conception séquentielle peut améliorer les performances.
Le journal 206 peut également généralement supporter plusieurs périphériques de stockage. C’est-à-dire que le journal 206 ne fait pas de distinction entre des blocs de cache de différents dispositifs cibles de stockage en cache d’intérêt. Ce support de commande multiple peut généralement conduire à une meilleure utilisation de l’espace dans le journal 206, car le support de commande multiple supprime généralement le besoin de pré-réserver de l’espace pour les différents périphériques de stockage. Sinon, le journal 206 pourrait contenir de l’espace non utilisé qui est pré-réservé pour un dispositif de stockage qui n’a pas eu besoin de l’espace, ce qui pourrait conduire à une utilisation inefficace des ressources.
Toutefois, un journal 206 sans zone de données d’invalidation 208 peut également présenter des performances en baisse. Un exemple de cas d’utilisation consiste à ce qu’un cache 104 puisse placer en cache plusieurs périphériques de stockage et fonctionner en mode d’écriture différée (c’est-à-dire différer l’écriture de données de cache mises à jour dans le stockage sous-jacent). Si l’éviction du cache 104 vers l’un quelconque des périphériques de stockage échoue, alors le système ne peut pas mettre en cache de nouvelles données, même de nouvelles données pour d’autres périphériques de stockage. Au lieu de cela, le système peut préserver les anciennes données, de sorte qu’elles puissent être écrites en différé sur le périphérique de stockage. La mise en œuvre non volatile basée sur la consignation décrite précédemment peut généralement s’attendre que l’éviction soit effectuée séquentiellement. Dans certains modes de réalisation, le cache 104 ne peut pas écarter des données pour un dispositif de stockage indisponible, sauf si l’utilisateur en fait explicitement la demande inverse.
Cependant, même avec un dispositif de stockage non disponible, le cache 104 peut continuer à desservir des opérations d’E/S pour fournir un service transparent à d’autres périphériques de stockage qui sont encore disponibles. Cette mise en cache transparente peut être effectuée comme suit : 1) Lors d’un échec de cache, le cache 104 peut faire passer l’opération d’E/S. 2) Lors d’un succès de lecture, le cache 104 peut desservir l’opération de lecture demandée depuis le cache 104. 3) Lors d’un succès d’écriture, le cache 104 peut soit (a) mettre à jour, soit (b) invalider les données demandées depuis le cache. L’une ou l’autre opération peut conduire à un cycle de lecture-modification-écriture pour les métadonnées 214, et une opération d’écriture pour les données 216 (par exemple, dans le cas d’une demande de mise à jour). Ainsi, tout succès d’écriture pourrait nécessiter une lecture et une écriture (pour une invalidation) ou 2 écritures (pour une mise à jour). Les deux scénarios peuvent représenter une sanction des performances globales. Chacune de ces approches peut détourner de l’approche basée sur la consignation utilisant un journal 206 sans zone de données d’invalidation 208 pour écrire des données. En outre, les scénarios peuvent présenter un risque de perte de données, car les opérations ne sont pas atomiques et pourraient bénéficier d’être exécutées en série.
La figure 2B illustre un exemple de schéma de principe de cache 104, conformément à certains modes de réalisation de la présente divulgation. Le cache 104 peut inclure une zone de données d’invalidation 208. La zone de données d’invalidation 208 peut généralement stocker des enregistrements d’invalidation 218 pour les blocs de cache qui sont supprimés, ou évincés, à partir du cache 104.
La zone de données d’invalidation 208 peut inclure une région séparée de cache 104 (par exemple, distincte du journal 206). Le système peut mapper des blocs de journal sous-jacents dans cette région séparée en utilisant des enregistrements d’invalidation 218. Dans certains modes de réalisation, le cache peut implémenter la région séparée au moyen d’un nom d’espace dédié, prédéterminé.
En conséquence, la zone de données d’invalidation 208 peut présenter les avantages suivants : 1) Maintenir une approche basée sur la consignation pour écrire des données de journal. C’est-à-dire que la conception de la zone de données d’invalidation 208 peut convertir des opérations d’écriture qui, autrement, pourrait être mises à jour potentiellement aléatoirement ou invalider des écritures dans des écritures séquentielles sur le dispositif de cache. 2) Mapper plusieurs blocs de journal en un seul bloc d’enregistrement d’invalidation (représenté sur la figure 3A). Par exemple, certains modes de réalisation de la zone de données d’invalidation 208 peuvent mapper trois blocs de journal dans un enregistrement d’invalidation. Par conséquent, l’espace utilisé pour la zone de données d’invalidation 208 peut être d’environ 0,5 % d’une taille totale de cache 104. 3) Du fait que la taille de la zone de données d’invalidation 208 peut être une petite fraction de la taille totale du cache 104, la zone de données d’invalidation 208 peut généralement être stockée entièrement dans une RAM. En outre, le stockage de la zone de données d’invalidation dans la mémoire RAM 208, en général, peut permettre d’éliminer le besoin de procéder à une opération de lecture au cours de l’invalidation. Même si la zone de données d’invalidation n’est pas généralement stockée dans la mémoire RAM, le système peut toujours présenter une réduction de 66 % du nombre de lectures requises. Ceci est dû au fait que les enregistrements pour trois blocs de journal peuvent être mappés à un bloc d’invalidation. 4) Mettre en paquet des entrées de blocs d’enregistrement d’invalidation peut permettre de réduire le temps système d’écriture, de sorte que plusieurs entrées sont écrites en une seule opération d’écriture. En outre, il peut y avoir une réduction de 66 % du nombre d’écritures. Généralement, la zone de données d’invalidation 208 peut offrir une solution transparente pour la gestion des erreurs et le maintien de la cohérence des données. En outre, la zone de données d’invalidation 208 peut offrir ces avantages sans généralement introduire une grande perte des performances en échange.
La figure 3A illustre un exemple de mappage entre un journal 206 et une zone de données d’invalidation 208, conformément à certains modes de réalisation de la présente divulgation. La figure 3A comprend un journal 206 et une zone de données d’invalidation 208. Le journal 206 comprend des blocs de journal 1-3. La zone de données d’invalidation 208 comprend un enregistrement d’invalidation 1. L’enregistrement d’invalidation 1 comprend des blocs de journal 1-3 mappés.
Dans certains modes de réalisation, les enregistrements d’invalidation peuvent généralement être stockés dans la mémoire cache 104, dans la zone de données d’invalidation séparée. Les enregistrements d’invalidation peuvent généralement utiliser des blocs de journal mappés associés à un enregistrement d’invalidation, pour représenter plusieurs blocs de journal associés au journal 206. Par exemple, le bloc de journal 1 peut correspondre au bloc de journal mappé 1, le bloc de journal 2 peut correspondre au bloc de journal mappé 2, et le bloc de journal 3 peut correspondre au bloc de journal mappé 3. En outre, les blocs de journal mappés 1-3 peuvent nécessiter que moins de métadonnées soient stockées que les blocs de journal sous-jacents correspondants 1-3. En conséquence, dans certains modes de réalisation, le système peut sélectionner un sous-ensemble de métadonnées à partir de blocs de journal sous-jacents 1-3, de sorte que tous les trois blocs de journal mappés puissent être stockés dans l’enregistrement d’invalidation 1.
La figure 3B illustre un autre exemple de mappage entre un journal 206 et une zone de données d’invalidation 208, conformément à certains modes de réalisation de la présente divulgation. La figure 3B comprend un journal 206 et une zone de données d’invalidation 208. Le journal 206 comprend un bloc de journal 1 avec des métadonnées 214 et des données 216. La zone de données d’invalidation 208 comprend un enregistrement d’invalidation 1. L’enregistrement d’invalidation 1 comprend un bloc de journal mappé 1. Le bloc de journal mappé 1 inclut des métadonnées 302. L’enregistrement d’invalidation 1 peut inclure à la fois une version stockée dans une mémoire cache et une version relativement plus rapide chargée dans une mémoire vive (RAM). La structure de données en RAM peut généralement améliorer les performances et de réduire le besoin de lire les données depuis le journal relativement plus lent ou depuis le cache 104. Dans certains modes de réalisation, un exemple de définition d’enregistrement d’invalidation 1 peut comprendre les lignes de code suivantes. /* Comme stocké dans le cache 104 */ struct invalidationrecordblock { unsigned char checksum[16]; // somme de contrôle de la totalité du bloc syntaxique struct mapped joumalblock joumal_block[3]; }
Un exemple d’enregistrement d’invalidation peut inclure plusieurs blocs de journal mappés (« joumalblock »), et un code de correction d’erreur (« checksum »).
Dans certains modes de réalisation de la structure de données d’enregistrement d’invalidation, un exemple de définition du bloc de journal mappé dont il est fait référence dans la structure de données d’enregistrement d’invalidation peut inclure les lignes suivantes : struct mappedjoumalblock { unsigned long long epoch; // époque du journal pendant l’écriture. unsigned int target lba[MAX_JOURNAL_ENTRY]; // stockage de décalage (4000 LBA alignées) }
Le bloc de journal mappé peut inclure une collection (par exemple, un tableau) d’adresses de mémoire et des décalages (« target lba »). Les adresses de mémoire peuvent identifier un bloc de mémoire d’intérêt, et les décalages peuvent identifier des blocs de mémoire spécifiques d’intérêt ou des emplacements de mémoire spécifiques d’intérêt dans les blocs de mémoire. La collection d’adresses de mémoire et de décalages dans le bloc de journal mappé peut mapper une collection correspondante d’adresses de mémoire et de décalages stockés dans des blocs de journal sous- jacents. Le bloc de journal mappé peut également inclure un horodatage (« époque ») qui peut correspondre à un horodatage correspondant stocké dans le bloc de journal sous-jacent.
Dans certains modes de réalisation, la structure de données en RAM représentant un enregistrement d’invalidation peut comprendre les lignes suivantes. /* Représentation en RAM de bloc d’enregistrement d’invalidation */ struct inraminvalidationrecordblock { unsigned char valid: 1; // Si ce bloc a été écrit avant unsigned char outstanding: 1 ; // La valeur max. peut uniquement être 1 à tout moment. void *waiting_creqs; // Attendre des demandes s’il y a déjà une écriture en suspens void *irb_cache_device; // Tampon contenant l’IRB sur le périphérique de cache }
La structure en RAM de données peut généralement améliorer les performances et réduire le besoin de lire les données depuis le journal relativement plus lent ou depuis le cache 104.
Le bloc de journal mappé peut représenter un bloc de journal. Dans certains modes de réalisation, un enregistrement d’invalidation peut contenir plusieurs blocs de journal mappés. Par exemple, la figure 3A illustre un enregistrement d’invalidation ayant une capacité de trois blocs de journal mappés (de sorte qu’il puisse y avoir un mappage 3 vers 1 depuis des blocs de journal vers un enregistrement d’invalidation). Le bloc de journal mappé peut stocker des entrées d’adresses de mémoire qui ont été invalidées dans le cache 104. Dans certains modes de réalisation, les adresses de mémoire peuvent être des adresses de blocs logiques (LBA). Bien que la présente divulgation décrive un suivi de trois blocs de journal au moyen d’un enregistrement d’invalidation unique, l’enregistrement d’invalidation peut contenir un nombre quelconque de blocs de journal mappés, par exemple déterminé sur la base du sous-ensemble de métadonnées choisi pour être stocké dans le bloc de journal mappé. Un exemple de bloc de journal peut avoir une taille d’environ 256 Ko et un exemple d’enregistrement d’invalidation peut avoir une taille d’environ 4 Ko. Du fait qu’il puisse y avoir un mappage 3 vers 1 entre des blocs de journal et des enregistrements d’invalidation, la zone de données d’invalidation 208 doit gérer efficacement l’espace. Par exemple, la zone de données d’invalidation 208 peut utiliser seulement environ 4 Ko pour tenir compte des 768 Ko (3 blocs de journal x 256 Ko par bloc de journal) de données dans le journal 206. En conséquence, les besoins en espace pour la zone de données d’invalidation 208 peuvent être d’environ 0,52 % (4 Ko/768 Ko). En outre, le mappage 3 vers 1 entre les blocs de journal mappés vers les enregistrements d’invalidation peut réduire d’environ 66 % le nombre d’opérations de lecture et d’écriture effectuées au cours du processus d’invalidation. Dans certains modes de réalisation, du fait de la petite taille de la zone de données d’invalidation 208 et de l’allocation efficace de l’espace, la zone de données d’invalidation 208 peut être stockée entièrement en mémoire vive (RAM) pour réduire ou même éliminer complètement le nombre d’opérations de lecture vers la mémoire cache 104.
Dans certains modes de réalisation, la zone de données d’invalidation 208 peut stocker un sous-ensemble de métadonnées 214 qui est suivi dans le journal 206. Cela peut efficacement contribuer à encore réduire la taille de la zone de données d’invalidation 208. Par exemple, les métadonnées 214 suivies dans le journal 206 peuvent inclure une adresse de mémoire (par exemple, une adresse de bloc logique (LBA)), un type de bloc de cache, un décalage, et une valeur de hachage pour la correction d’erreur. En revanche, dans certains modes de réalisation, les métadonnées 302 suivies dans la zone de données d’invalidation 208 peuvent inclure un sous- ensemble de métadonnées 214 suivies dans le journal 206. Par exemple, le système peut choisir de suivre uniquement une adresse de mémoire correspondante dans les métadonnées 302. Suivre uniquement un sous-ensemble de métadonnées peut améliorer l’efficacité spatiale ou la capacité de la zone de données d’invalidation 208. D’autres modifications dépendant des utilisations et des métadonnées stockées dans le journal 206 et la zone de données d’invalidation 208 peuvent encore affecter cette taille. Des exemples de modifications peuvent inclure une augmentation de la taille des blocs de journal, une diminution de la taille des adresses de mémoire stockées dans un bloc de journal mappé, etc. Certains modes de réalisation du système peuvent tronquer la taille des adresses de mémoire stockées dans un bloc de journal mappé. Dans une implémentation, la troncature peut être basée sur une taille de stockage du dispositif de stockage sous-jacent. Par exemple, si le dispositif de stockage est suffisamment petit, le système peut stocker des adresses de mémoire d’environ quatre octets dans le bloc de journal mappé, par rapport à une adresse de mémoire totalement développée d’environ huit octets, stockée dans un bloc de journal correspondant.
Dans une autre mise en œuvre, la troncature peut inclure de déterminer un décalage sur la base d’une adresse de mémoire correspondante utilisée dans le stockage sous-jacent, et de stocker le décalage à la place de l’adresse de mémoire. Des modes de réalisation de la mémoire cache peuvent stocker des blocs de données aux tailles d’environ 4 Ko. (Si une demande d’E/S porte sur une taille plus petite, le cache peut alors récupérer les données restantes associées au bloc de données à partir du stockage et peut mettre en cache la totalité du contenu du bloc de données de 4 Ko). Par conséquent, dans certains modes de réalisation, la troncature peut inclure de convertir une adresse de mémoire (comme une LBA) de stockage sous-jacent dans des décalages. Dans certains modes de réalisation, les décalages peuvent être d’environ 4 Ko. Par exemple, un décalage 0 peut représenter les 4 premiers Ko sur le périphérique de stockage, un décalage 1 peut représenter les 4 Ko suivants sur le périphérique de stockage, etc. En conséquence, le cache peut convertir une adresse de mémoire, par exemple, une LBA de 512 octets, à une prochaine LBA alignée de 4 Ko disponible. Plutôt que de stocker une LBA complète, le système peut convertir une LBA complète en un décalage qui utilise un plus petit nombre d’octets, et stocker le décalage dans l’enregistrement d’invalidation le bloc de journal mappé. Par exemple, LBA 0-7 dans le stockage sous-jacent peut correspondre à LBA 0 dans le cache avec un décalage optionnel. Dans certains modes de réalisation de la zone de données d’invalidation, un champ décalage d’une taille de 4 B peut ainsi adresser jusqu’à 16 téraoctets de stockage sous-jacent (232 x 4096). Pour les plus grands dispositifs de stockage, certains modes de réalisation du système peuvent augmenter la taille de bloc de cache à environ 8 Ko ou plus, augmenter la taille de décalage à environ 5 octets, etc.
Certains modes de réalisation de cache 104 peuvent invalider des blocs de cache en déterminant un mappage entre le journal 206 et la zone de données d’invalidation 208. C’est-à-dire que le cache 104 peut déterminer un enregistrement d’invalidation approprié, un bloc de journal mappé, et un index correspondant dans une zone de données d’invalidation 208 pour un bloc de données, sur la base du bloc de journal et d’un index dans le journal 206.
Par exemple, supposons que le cache 104 procède à une invalidation d’un bloc de données résidant dans le bloc de journal 1, à l’index 3 (304a). Sur la base du bloc de journal et de l’index dans le journal 206, le cache 104 peut généralement déterminer l’enregistrement d’invalidation correspondant, le bloc de journal mappé, et l’index dans le bloc de journal mappé. Tout d’abord, le cache 104 peut déterminer un enregistrement d’invalidation sur la base du bloc de journal correspondant. Du fait que les blocs de journal peuvent effectuer un mappage 3 vers 1 sur la capacité d’enregistrements d’invalidation, certains modes de réalisation du cache 104 peuvent exécuter une opération de division et une fonction de plafonnement (c’est-à-dire arrondir) pour déterminer l’enregistrement d’invalidation correspondant. Par exemple, pour le bloc de journal 1, le système peut calculer 1/3 = 0,33... et [0,33] = 1, ce qui mappe le bloc de journal 1 à l’enregistrement d’invalidation 1. A titre d’autre exemple, si le système avait mappé le bloc de journal 5 à un enregistrement d’invalidation, 5/3 = 1,66... et [1,661 = 2, ce qui mappe le bloc de journal 5 à l’enregistrement d’invalidation 2.
Ensuite, le cache 104 peut déterminer un bloc de journal mappé sur la base d’un bloc de journal. Dans certains modes de réalisation, le cache 104 peut utiliser une opération modulo pour déterminer un bloc de journal mappé sur la base du numéro de bloc de journal. Par exemple, pour le bloc de journal 1, le système peut calculer 1 mod 3 = 1, ce qui mappe le bloc de journal 1 au bloc de journal mappé 1. De même, si le système avait mappé le bloc de journal 5 à un bloc de journal mappé, 5 mod 3 = 2, ce qui mappe le bloc de journal 5 au bloc de journal mappé 2 dans un enregistrement d’invalidation 2 (tel que déterminé plus tôt).
Enfin, le cache 104 peut déterminer un index dans le bloc de journal mappé qui correspond à un index dans le bloc de journal sous-jacent. Certains modes de réalisation du cache 104 peuvent utiliser le même index dans le bloc de journal mappé que l’index utilisé dans le bloc de journal sous-jacent. Autrement dit, lors de l’écriture des entrées de bloc de journal correspondantes dans la zone de données d’invalidation 208, les entrées de bloc de journal peuvent être ajoutées au même index, dans le tableau « targetlba » du bloc de journal mappé, comme utilisé dans un tableau « target lba » correspondant du bloc de journal. En conséquence, l’index dans le bloc de journal mappé peut être facilement et rapidement déterminé sur la base de l’index dans le bloc de journal sous-jacent.
Pour effectuer un mappage inverse (c’est-à-dire, pour déterminer un bloc de journal et un index correspondant sur la base d’un enregistrement d’invalidation, d’un bloc de journal mappé, et d’un index), le cache 104 peut effectuer les opérations inverses de celles décrites ci-dessus. Par exemple, le cache 104 peut identifier des informations sur une adresse de mémoire pour un bloc de cache invalidé sur la base des métadonnées 302 stockées dans le bloc de journal mappé. Le cache 104 peut déterminer le numéro de bloc de journal sur la base du numéro d’enregistrement d’invalidation, et l’index pour le bloc de journal peut être déduit de l’index utilisé dans le bloc de journal mappé.
La figure 4 illustre un exemple de procédé 400 d’invalidation utilisant la zone de données d’invalidation, conformément à certains modes de réalisation de la présente divulgation. Dans certains modes de réalisation, un procédé 400 peut comprendre de déterminer un bloc de journal pour une adresse de mémoire dans une opération d’écriture reçue (étape 402) ; de déterminer un bloc de journal mappé et un décalage sur la base du bloc de journal déterminé et d’un enregistrement d’invalidation correspondant de la zone de données d’invalidation (étape 404) ; de déterminer s’il y a des opérations d’écriture en suspens (étape 406) ; si oui, agréger les opérations d’écriture et exécuter les opérations d’écriture sous la forme d’une seule écriture dans le cache (étape 408) ; si non, exécuter l’opération d’écriture reçue (étape 410).
Tout d’abord, le procédé 400 détermine un bloc de journal pour une adresse de mémoire dans une opération d’écriture reçue (étape 402). Certains modes de réalisation du procédé 400 peuvent identifier le bloc de journal sur la base de l’adresse de bloc logique (LBA) dans l’opération d’écriture reçue. Ou, lors d’un succès d’écriture (signifiant que la LBA a été préalablement mise en mémoire cache), le procédé 400 peut identifier le bloc de journal sur la base de l’adresse LBA à laquelle le bloc de cache est stocké dans le cache.
Ensuite, le procédé 400 continue pour déterminer un bloc de journal mappé sur la base du bloc de journal déterminé et d’un enregistrement d’invalidation correspondant de la zone de données d’invalidation (étape 404). Dans certains modes de réalisation, l’enregistrement d’invalidation peut être déterminé en effectuant des opérations de division et des opérations de plafonnement sur le numéro de bloc de journal. Certains modes de réalisation peuvent également déterminer l’index pour le bloc de journal mappé en utilisant l’index utilisé dans le bloc de journal sous-jacent. Par exemple, lorsque le système utilise les mêmes index pour le bloc de journal mappé et le bloc de journal sous-jacent, l’index peut être déterminé facilement et rapidement.
Ensuite, le procédé 400 peut déterminer s’il y a des opérations d’écriture en suspens (étape 406). Dans certains modes de réalisation, cela peut être déterminé en utilisant une structure de données en mémoire vive (RAM) correspondant à l’enregistrement d’invalidation. Par exemple, la structure de données en mémoire vive peut contenir un champ (« en suspens ») qui identifie si des opérations d’écriture sont en suspens. Un avantage de l’utilisation de la structure de données en RAM est d’éviter une opération de lecture relativement lente au niveau de la mémoire cache sous-jacente pour récupérer l’enregistrement d’invalidation stocké.
Si le procédé 400 détermine que des opérations d’écriture sont en suspens (étape 406 : Oui), les opérations d’écriture et l’exécution des opérations d’écriture peuvent être regroupées en une seule écriture sur le cache (étape 408). Certains modes de réalisation du procédé 400 placent en file d’attente les écritures ultérieures lors de la détermination que des opérations d’écriture sont en suspens. Après que l’opération d’écriture précédente est terminée, le procédé 400 écrit les écritures en file d’attente dans le cache sous la forme d’une seule écriture qui contient les informations agrégées de toutes les mises à jour. Dans certains modes de réalisation, l’agrégation peut comprendre d’identifier des opérations d’écriture qui opèrent sur le même bloc de données, de commander les opérations d’écriture sur la base de l’horodatage, et de déterminer le résultat final des opérations d’écriture ordonnées. De cette manière, ce regroupement en lot ou cette agrégation d’opérations d’écriture permettent au procédé 400 de réduire encore davantage le nombre d’opérations de lecture et d’écriture utilisées pour une invalidation. S’il est déterminé qu’aucune opération d’écriture n’est en suspens (étape 406 : Non), le procédé 400 peut se poursuivre pour exécuter l’opération d’écriture reçue (étape 410).
La figure 5 illustre un exemple de procédé 500 de récupération de mémoire cache, conformément à certains modes de réalisation de la présente divulgation. La récupération de cache se réfère à une situation dans laquelle le cache peut bénéficier d’une reconstruction basée sur le journal et sur la zone de données d’invalidation, par exemple après une panne de courant, un arrêt incorrect du système, ou tout autre événement imprévu. Le procédé 500 peut comprendre de reconstruire le cache sur la base du journal (étape 502) ; ensuite, pour chaque bloc de journal mappé dans chaque enregistrement d’invalidation (étape 504) : déterminer si un bloc de cache correspondant est valide sur la base d’une entrée de journal mappé (étape 506) ; si oui, revenir à l’étape 504, si non, évincer le bloc erroné du cache (étape 508).
Tout d’abord, le procédé 500 reconstruit le cache sur la base du journal (étape 502). Certains modes de réalisation du système peuvent faire l’hypothèse que le contenu du journal représente généralement des données valides qui doivent être reconstruites dans le cache. Dans certains modes de réalisation, le système peut reconstituer le cache en récupérant chaque bloc de journal du journal, et en itérant un traitement des métadonnées dans chaque bloc de journal pour reconstruire chaque bloc de cache. Cependant, les métadonnées de bloc de journal peuvent en fait contenir des blocs de cache qui pourraient avoir été invalidés. Le système peut ultérieurement corriger cette hypothèse initiale des données généralement valides basées sur la zone de données d’invalidation. Par exemple, le système peut identifier des blocs de cache non valides sur la base de la zone de données d’invalidation, et évincer ces blocs de cache erronés du cache.
Ensuite, le procédé 500 procède à une itération à travers chaque bloc de journal mappé dans chaque enregistrement d’invalidation (étape 504). Pour chaque bloc de journal mappé, les métadonnées sont traitées dans le bloc de journal mappé pour déterminer si les blocs de cache correspondants sont en fait valides ou non valides (étape 506). Certains modes de réalisation peuvent déterminer si un bloc de cache est valide en déterminant si les métadonnées dans le bloc de journal mappé sont cohérentes avec les métadonnées sous-jacentes dans le bloc de journal sous-jacent. Par exemple, la cohérence des métadonnées sous-jacentes dans le bloc de journal sous-jacent peut être déterminée par la localisation du numéro de bloc de journal correspondant et de l’index sur la base d’opérations de division, de fonctions de plafonnement et d’opérations modulo. Ensuite, les métadonnées stockées au numéro de bloc de journal déterminé et l’index déterminé peuvent être préparés avec les métadonnées stockées dans le bloc de journal mappé. Par exemple, supposons que le procédé 500 identifie, sur la base du bloc de journal mappé, que l’adresse de mémoire 8 devrait être trouvée au niveau du bloc de journal sous-jacent 1, index 3. Le procédé 500 peut alors récupérer le contenu correspondant du bloc de journal 1, à l’index 3 des métadonnées. Si ce bloc de journal suit en fait un bloc de cache correspondant à une adresse de mémoire 8, il peut être déterminé que le bloc de cache correspondant à l’adresse de mémoire 8 est non valide, car le bloc de cache attendu basé sur la zone de données d’invalidation et le bloc de journal mappé correspond en fait au bloc de cache réel suivi dans le bloc de journal sous-jacent correspondant. D’autre part, supposons que le procédé 500 identifie, sur la base du bloc de journal mappé, qu’un bloc de cache correspondant à l’adresse de mémoire 16 devrait être trouvé au niveau du bloc de journal sous-jacent 1, index 4. Si le bloc de cache réel stocké au niveau du bloc de journal sous-jacent 1, index 4, ne correspond pas à l’adresse de mémoire 16, le procédé 500 peut poursuivre pour traiter les prochaines métadonnées, car le bloc de cache peut rester dans le cache lorsque le bloc de cache prévu sur la base de la zone de données d’invalidation et du bloc de journal mappé ne correspond pas au bloc de cache réel suivi dans le bloc de journal sous-jacent correspondant.
Si les métadonnées correspondent, le procédé 500 peut déterminer le bloc de cache non valide (étape 506 : Non). En conséquence, le procédé 500 peut évincer, ou écarter, le bloc non valide (c’est-à-dire erroné) de la mémoire cache (étape 508). Si les métadonnées ne correspondent pas, le procédé 500 peut poursuivre pour traiter les métadonnées suivantes correspondant au bloc de journal mappé, ou poursuivre pour traiter le bloc de journal mappé suivant si le procédé 500 a traité toutes les métadonnées dans le bloc de journal mappé (étape 506 : Oui).
La zone de données d’invalidation peut en outre offrir des avantages supplémentaires autour de (1) la mise en cache transparente, et (2) du changement de mode de cache dynamique entre un mode d’écriture différée et un mode d’écriture immédiate. La mise en cache transparente se réfère à la capacité pour un administrateur ou un utilisateur de retirer, à volonté, le cache du système. Le mode de changement de mode de cache dynamique se réfère à la capacité pour un administrateur ou un utilisateur de changer le mode de cache entre un mode d’écriture différée et un mode d’écriture immédiate, sans avoir à éteindre le système. La zone de données d’invalidation peut permettre la mise en cache transparente et le changement de mode dynamique sans introduire de latence importante au niveau des opérations d’E/S en cours. Dans certains modes de réalisation, le cache peut éviter la latence en écartant toutes les données. Si le cache est en mode d’écriture différée, le cache vide généralement ses données erronées vers le dispositif de stockage sous-jacent (à savoir, « écrit en différé » les données) avant que le cache puisse éliminer ou évincer les données. Auparavant, le cache a vidé ses données en mettant en pause toutes les opérations d’E/S en suspens avant de procéder au vidage. Toutefois, l’arrêt ou la mise en pause de toutes les opérations d’E/S en suspens peuvent introduire une latence non souhaitée, car il n’y a pas de limite supérieure à la quantité de temps utilisée pour le vidage. Des exemples de facteurs qui peuvent affecter le temps de vidage peuvent inclure la quantité de données erronées, l’aspect aléatoire, la vitesse du disque, etc. Dans certains modes de réalisation, la zone de données d’invalidation améliore les opérations d’E/S en cours en mettant le cache en mode pause et en assurant les opérations d’E/S comme suit : 1) Le cache laisse passer les échecs de cache 2) Le cache sert les succès de lecture 3) Le cache utilise la zone de données d’invalidation pour invalider des succès d’écriture et laisse passer les écritures sur le stockage sous-jacent.
Après que le vidage du cache est terminé, le cache peut écarter toutes les données en toute sécurité. L’homme du métier appréciera que diverses illustrations décrites ici puissent être mises en œuvre sous la forme d’un matériel électronique, de logiciels, ou d’une combinaison des deux. Pour illustrer cette interchangeabilité du matériel et des logiciels, divers blocs d’illustratifs, modules, éléments, composants, procédés et algorithmes ont été décrits ci-dessus généralement en termes relatifs à leur fonctionnalité. Que cette fonctionnalité soit mise en œuvre en sous une forme matérielle, logicielle ou une combinaison des deux dépend de l’application particulière et des contraintes de conception imposées au système global. Des artisans qualifiés peuvent mettre en œuvre la fonctionnalité décrite de diverses manières pour chaque application particulière. Divers composants et blocs peuvent être agencés différemment (ils peuvent par exemple être disposés dans un ordre différent, ou répartis d’une autre façon), tout cela sans sortir du cadre de la technologie en question.
En outre, une mise en œuvre de la zone de données d’invalidation peut être réalisée de manière centralisée dans un système informatique, ou d’une manière distribuée où différents éléments sont répartis sur plusieurs systèmes informatiques interconnectés. Tout type de système informatique, ou tout autre appareil adapté pour exécuter les procédés décrits ici, est adapté pour exécuter les fonctions décrites dans la présente.
Elne combinaison typique de matériel et de logiciel pourrait être un système informatique universel avec un programme informatique qui, lorsqu’il est chargé et exécuté, commande le système informatique de telle sorte qu’il exécute les procédés décrits dans la présente. Les procédés peuvent également être incorporés dans un produit programme informatique, qui comprend toutes les fonctionnalités permettant l’implémentation des procédés décrits dans la présente, et qui, lorsqu’il est chargé dans un système informatique, est en mesure d’exécuter ces procédés.
Dans le présent contexte, « programme d’ordinateur » ou « application » signifie toute expression, dans tout langage, code ou notation, d’un ensemble d’instructions destinées à amener un système disposant d’une capacité de traitement de l’information à exécuter une fonction particulière, soit directement, soit après, l’une ou l’autre, ou les deux actions suivantes : a) conversion dans un autre langage, code ou notation ; b) reproduction sous une forme matérielle différente. De manière significative, les systèmes et les procédés décrits dans la présente peuvent également être incorporés sous d’autres formes spécifiques sans s’écarter de l’esprit ou des attributs essentiels de l’invention et, en conséquence, il convient de faire référence aux revendications suivantes, plutôt qu’à la spécification qui précède, pour indiquer la portée des systèmes et des procédés.
La présente invention a été décrite en détail avec une référence spécifique à ces modes de réalisation illustrés. Il sera toutefois évident que diverses modifications et divers changements peuvent être apportés tout en restant dans l’esprit et la portée de l’invention telle que décrite dans la spécification qui précède, et de tels modifications et changements doivent être considérés comme équivalents et faisant partie de cette description.

Claims (20)

  1. Revendications
    1. Cache comprenant : un journal configuré pour suivre des blocs de données stockés dans le cache ; et une zone de données d’invalidation configurée pour suivre des blocs de données invalidés associés aux blocs de données suivis dans le journal, où la zone de données d’invalidation se situe dans une région séparée du cache par rapport au journal.
  2. 2. Cache selon la revendication 1, dans lequel le journal est configuré pour suivre des métadonnées pour les blocs de données, et dans lequel les métadonnées comprennent une adresse de mémoire correspondant au bloc de données, et dans lequel la zone de données d’invalidation est configurée pour suivre des métadonnées associées aux blocs de données invalidés, et dans lequel les métadonnées associées comprennent une adresse de mémoire correspondant au bloc de données invalidé.
  3. 3. Cache selon la revendication 2, dans lequel le journal est configurée pour suivre les blocs de données en utilisant des blocs de journal, où les blocs de journal sont configurés pour stocker les métadonnées pour les blocs de données ; et dans lequel la zone de données d’invalidation est configurée pour suivre les métadonnées associées aux blocs de données non valides en utilisant des enregistrements d’invalidation et des blocs de journal mappés, où les blocs de journal mappés sont configurés pour stocker les métadonnées associées pour les blocs de données non valides, et où les enregistrements d’invalidation sont configurés pour stocker les blocs de journal mappés.
  4. 4. Cache selon la revendication 3, dans lequel les métadonnées suivies dans le journal comprennent en outre un index dans un ensemble de métadonnées stocké dans chaque bloc de journal, et dans lequel les métadonnées suivies dans la zone de données d’invalidation comprennent en outre un index dans un ensemble de métadonnées stockées dans chaque bloc de journal mappé.
  5. 5. Cache selon la revendication 3, dans lequel le cache est configuré pour déterminer un numéro d’enregistrement d’invalidation associé à un enregistrement d’invalidation dans la zone de données d’invalidation sur la base d’un numéro de bloc de journal correspondant associé à un bloc de journal.
  6. 6. Cache selon la revendication 3, dans lequel le cache est configuré pour déterminer un numéro de bloc de journal mappé associé à un bloc de journal mappé dans la zone d’invalidation sur la base d’un numéro de bloc de journal correspondant associé à un bloc de journal.
  7. 7. Cache selon la revendication 4, dans lequel l’index suivi dans le journal est sélectionné pour avoir la même valeur que l’index suivi dans la zone de données d’invalidation.
  8. 8. Cache selon la revendication 1, dans lequel l’adresse de mémoire suivie dans la zone de données d’invalidation est tronquée par rapport à l’adresse de mémoire suivie dans le journal, et dans lequel la troncature est déterminée sur la base d’au moins un élément parmi une taille de stockage d’un dispositif de stockage sous-jacent étant mis en cache et d’un décalage déterminé sur la base d’une adresse de mémoire d’un bloc dans le dispositif de stockage sous-jacent.
  9. 9. Procédé pour invalider un bloc dans un cache, le procédé comprenant les étapes suivantes : déterminer un bloc de journal suivant une adresse de mémoire associée à une opération d’écriture reçue, le bloc de journal étant stocké dans un journal du cache ; déterminer un bloc de journal mappé sur la base du bloc de journal déterminé et sur la base, en outre, d’un enregistrement d’invalidation, le bloc de journal mappé et l’enregistrement d’invalidation étant stockés dans une zone de données d’invalidation du cache ; déterminer si des opérations d’écriture sont en suspens ; si des opérations d’écriture sont en suspens, agréger les opérations d’écriture en suspens et exécuter une seule opération d’écriture sur la base des opérations d’écriture agrégées ; et s’il n’y a pas d’opérations d’écriture en suspens, exécuter l’opération d’écriture reçue.
  10. 10. Procédé selon la revendication 9, dans lequel déterminer le bloc de journal mappé comprend déterminer un numéro de bloc de journal mappé pour le bloc de journal mappé en : déterminant un numéro d’enregistrement d’invalidation en divisant un numéro de bloc de journal associé au bloc de journal déterminé par une capacité de l’enregistrement d’invalidation dans la zone de données d’invalidation et en calculant une fonction de plafonnement du résultat de la division, le numéro d’enregistrement d’invalidation identifiant l’enregistrement d’invalidation ; et déterminant le numéro de bloc de journal mappé en calculant une opération modulo du numéro de bloc de journal avec la capacité de l’enregistrement d’invalidation.
  11. 11. Procédé selon la revendication 9, dans lequel déterminer si des opérations d’écriture sont en suspens comprend récupérer un champ d’une structure de données en mémoire vive correspondant à l’enregistrement d’invalidation.
  12. 12. Procédé selon la revendication 9, dans lequel agréger des opérations d’écriture en suspens comprend les étapes suivantes : placer en file d’attente des opérations d’écriture ultérieures ; identifier les opérations d’écriture qui opèrent sur le même bloc de données ; et déterminer l’opération d’écriture unique sur la base des opérations d’écriture qui opèrent sur le même bloc de données.
  13. 13. Procédé selon la revendication 9, dans lequel la zone de données d’invalidation se situe dans une région séparée du cache par rapport au journal.
  14. 14. Procédé selon la revendication 9, dans lequel le cache comprend un cache de proximité de contenu ; et dans lequel le journal suit au moins un des blocs de données associés et des blocs de données indépendants dans le cache de proximité de contenu.
  15. 15. Procédé de récupération d’un cache, le procédé comprenant les étapes suivantes : déterminer une reconstruction initiale du cache sur la base d’un journal du cache ; pour chaque bloc de journal mappé dans un enregistrement d’invalidation dans une zone de données d’invalidation du cache, déterminer si un bloc de données correspondant suivi dans le journal est valide, sur la base du bloc de journal mappé ; et si le bloc de données correspondant est déterminé comme n’étant pas valide, évincer le bloc de données correspondant de la reconstruction initiale du cache.
  16. 16. Procédé selon la revendication 15, dans lequel déterminer la reconstruction initiale comprend de récupérer des blocs de données et des métadonnées décrivant les blocs de données, les blocs de données récupérés et les métadonnées étant récupérés à partir du journal.
  17. 17. Procédé selon la revendication 15, dans lequel déterminer si le bloc de données correspondant suivi dans le journal est valide comprend de comparer les métadonnées décrivant le bloc de données correspondant suivi dans le journal aux métadonnées décrivant le bloc de données correspondant suivi dans le bloc de journal mappé.
  18. 18. Procédé selon la revendication 17, dans lequel comparer les métadonnées comprend de comparer une première adresse de mémoire et un premier index pour le bloc de données correspondant suivi dans le journal à une seconde mémoire et un second index suivi dans le bloc de journal mappé.
  19. 19. Procédé selon la revendication 15, dans lequel la zone de données d’invalidation se situe dans une région séparée du cache par rapport au journal.
  20. 20. Procédé selon la revendication 15, dans lequel le cache comprend un cache de proximité de contenu ; et dans lequel le journal suit au moins un des blocs de données associés et des blocs de données indépendants dans le cache de proximité de contenu.
FR1555325A 2014-06-26 2015-06-11 Zone de donnees d'invalidation pour cache Active FR3023030B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14316256 2014-06-26
US14/316,256 US9501418B2 (en) 2014-06-26 2014-06-26 Invalidation data area for cache

Publications (2)

Publication Number Publication Date
FR3023030A1 FR3023030A1 (fr) 2016-01-01
FR3023030B1 true FR3023030B1 (fr) 2019-10-18

Family

ID=53785168

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1555325A Active FR3023030B1 (fr) 2014-06-26 2015-06-11 Zone de donnees d'invalidation pour cache

Country Status (5)

Country Link
US (4) US9501418B2 (fr)
CN (1) CN105302744B (fr)
DE (1) DE102015007709A1 (fr)
FR (1) FR3023030B1 (fr)
GB (3) GB2540681B (fr)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9501418B2 (en) 2014-06-26 2016-11-22 HGST Netherlands B.V. Invalidation data area for cache
US11061876B2 (en) * 2016-11-15 2021-07-13 Sap Se Fast aggregation on compressed data
US10642796B2 (en) * 2017-07-18 2020-05-05 International Business Machines Corporation File metadata verification in a distributed file system
CN109284066B (zh) * 2017-07-19 2022-09-30 阿里巴巴集团控股有限公司 一种数据处理方法、装置、设备及系统
JP6731553B2 (ja) * 2017-07-20 2020-07-29 株式会社日立製作所 分散ストレージシステム及び分散ストレージ制御方法
US10210086B1 (en) 2017-08-16 2019-02-19 International Business Machines Corporation Fast cache demotions in storage controllers with metadata
US10877890B2 (en) * 2018-06-01 2020-12-29 Intel Corporation Providing dead-block prediction for determining whether to cache data in cache devices
KR20210011176A (ko) 2019-07-22 2021-02-01 에스케이하이닉스 주식회사 메모리 시스템의 액세스 동작 방법 및 장치
KR20210011216A (ko) 2019-07-22 2021-02-01 에스케이하이닉스 주식회사 메모리 시스템의 메타 데이터 관리 방법 및 장치
KR20210014338A (ko) 2019-07-30 2021-02-09 에스케이하이닉스 주식회사 데이터 저장 장치, 데이터 처리 시스템 및 데이터 저장 장치의 동작 방법
KR20200119059A (ko) * 2019-04-09 2020-10-19 에스케이하이닉스 주식회사 메모리 시스템 및 그것의 동작방법
KR20200132047A (ko) 2019-05-15 2020-11-25 에스케이하이닉스 주식회사 메모리 시스템에서 맵 데이터를 전송하는 방법 및 장치
KR20210011201A (ko) 2019-07-22 2021-02-01 에스케이하이닉스 주식회사 메모리 시스템 및 그의 온도 조절 방법
US11237973B2 (en) 2019-04-09 2022-02-01 SK Hynix Inc. Memory system for utilizing a memory included in an external device
KR102497130B1 (ko) 2021-11-11 2023-02-07 삼성전자주식회사 스토리지 장치 및 그것의 동작 방법

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997001139A1 (fr) * 1995-06-23 1997-01-09 Elonex Plc Organe de commande de pile de disques a ecriture synchrone perfectionnee
IL145552A0 (en) * 1999-03-23 2002-06-30 Univ James Cook Organ arrest, protection and preservation
US7043610B2 (en) * 2002-08-19 2006-05-09 Aristos Logic Corporation System and method for maintaining cache coherency without external controller intervention
CN100377117C (zh) * 2005-07-14 2008-03-26 中国科学院计算技术研究所 用于虚实地址变换及读写高速缓冲存储器的方法及装置
CN100370440C (zh) * 2005-12-13 2008-02-20 华为技术有限公司 处理器系统及其数据操作方法
US7627713B2 (en) * 2005-12-29 2009-12-01 Intel Corporation Method and apparatus to maintain data integrity in disk cache memory during and after periods of cache inaccessibility
JP5104340B2 (ja) * 2007-04-24 2012-12-19 富士通株式会社 計算機装置およびそのキャッシュリカバリ方法
CN101201800B (zh) * 2007-12-21 2010-06-09 福建星网锐捷网络有限公司 数据处理方法和装置
US8275970B2 (en) * 2008-05-15 2012-09-25 Microsoft Corp. Optimizing write traffic to a disk
EP2180408B1 (fr) * 2008-10-23 2018-08-29 STMicroelectronics N.V. Procédé pour l'écriture et la lecture de données dans une mémoire non volatile programmable et électriquement effaçable
US20110191522A1 (en) * 2010-02-02 2011-08-04 Condict Michael N Managing Metadata and Page Replacement in a Persistent Cache in Flash Memory
US20120215970A1 (en) * 2011-02-22 2012-08-23 Serge Shats Storage Management and Acceleration of Storage Media in Clusters
US9495301B2 (en) * 2012-08-07 2016-11-15 Dell Products L.P. System and method for utilizing non-volatile memory in a cache
US10055352B2 (en) * 2014-03-11 2018-08-21 Amazon Technologies, Inc. Page cache write logging at block-based storage
US9501418B2 (en) 2014-06-26 2016-11-22 HGST Netherlands B.V. Invalidation data area for cache

Also Published As

Publication number Publication date
GB2546634B (en) 2017-11-22
US20190317900A1 (en) 2019-10-17
GB2540681A (en) 2017-01-25
DE102015007709A1 (de) 2015-12-31
US10810128B2 (en) 2020-10-20
US10445242B2 (en) 2019-10-15
CN105302744B (zh) 2019-01-01
US9501418B2 (en) 2016-11-22
GB201509965D0 (en) 2015-07-22
CN105302744A (zh) 2016-02-03
GB201701188D0 (en) 2017-03-08
GB2540681B (en) 2017-06-14
FR3023030A1 (fr) 2016-01-01
US20170068623A1 (en) 2017-03-09
GB2529035B (en) 2017-03-15
US11372771B2 (en) 2022-06-28
GB2546634A (en) 2017-07-26
US20210042235A1 (en) 2021-02-11
GB2529035A (en) 2016-02-10
US20150378925A1 (en) 2015-12-31

Similar Documents

Publication Publication Date Title
FR3023030B1 (fr) Zone de donnees d'invalidation pour cache
US9348760B2 (en) System and method for efficient flash translation layer
US20190243558A1 (en) Two-level system main memory
EP2666111B1 (fr) Stockage de données sur des noeuds de stockage
US9772949B2 (en) Apparatus, system and method for providing a persistent level-two cache
FR2834809A1 (fr) Dispositif pour moteur de compression de memoire cache pour la compression de donnees sur des memoires cache integrees pour augmenter la taille de memoire cache effective
US11567871B2 (en) Input/output patterns and data pre-fetch
FR3033061A1 (fr)
CN108647151A (zh) 一种全闪系统元数据落盘方法、装置、设备及存储介质
FR3026512A1 (fr)
US10095624B1 (en) Intelligent cache pre-fetch
Kim et al. Reducing excessive journaling overhead with small-sized NVRAM for mobile devices
FR3027128A1 (fr)
US8904128B2 (en) Processing a request to restore deduplicated data
US11176034B2 (en) System and method for inline tiering of write data
US11061585B1 (en) Integration of NVMe device with DRAM cache system and method
US10423533B1 (en) Filtered data cache eviction
KR102403063B1 (ko) 모바일 디바이스 및 모바일 디바이스의 메모리 관리 방법
CN110825652B (zh) 淘汰磁盘块上的缓存数据的方法、装置及设备
US20210034516A1 (en) System and method for improving write performance for log structured storage systems
US20180316758A1 (en) Method and apparatus for logical mirroring to a multi-tier target node
FR3074317B1 (fr) Procede d'acces a une zone memoire non volatile de type flash d'un element securise, tel qu'une carte a puce
KR101663425B1 (ko) 저장장치의 성능 및 내구성 향상을 위해 다중 오픈 블록을 관리하는 메모리 저장 장치 및 방법
KR20160126472A (ko) 비휘발성 메모리를 이용한 프로그램의 시작 시간 최적화 장치 및 방법

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLSC Publication of the preliminary search report

Effective date: 20181207

PLFP Fee payment

Year of fee payment: 5

TP Transmission of property

Owner name: WESTERN DIGITAL TECHNOLOGIES, INC., US

Effective date: 20200319

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10