FR3084496A1 - Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees - Google Patents

Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees Download PDF

Info

Publication number
FR3084496A1
FR3084496A1 FR1856927A FR1856927A FR3084496A1 FR 3084496 A1 FR3084496 A1 FR 3084496A1 FR 1856927 A FR1856927 A FR 1856927A FR 1856927 A FR1856927 A FR 1856927A FR 3084496 A1 FR3084496 A1 FR 3084496A1
Authority
FR
France
Prior art keywords
page
data
node
file
version
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.)
Granted
Application number
FR1856927A
Other languages
English (en)
Other versions
FR3084496B1 (fr
Inventor
Xiao Han
Emile-Hugo Spir
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Priority to FR1856927A priority Critical patent/FR3084496B1/fr
Publication of FR3084496A1 publication Critical patent/FR3084496A1/fr
Application granted granted Critical
Publication of FR3084496B1 publication Critical patent/FR3084496B1/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
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

Le procédé de génération comprend : - l'initialisation (E10) à partir de la version initiale du fichier d'une version courante d'un graphe comprenant une pluralité de nœuds et d'arcs orientés, dans lequel chaque nœud représente une page de la mémoire persistante du dispositif occupée par le fichier, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à des données contenues dans la page de départ à transférer vers la page de destination pour obtenir la version finale du fichier ; - tant que la version courante du graphe comprend un arc orienté, une itération de traitement comprenant : ○ la sélection (E30) dans la version courante du graphe d'un arc orienté allant d'un premier nœud représentant une première page vers un deuxième nœud représentant une deuxième page ; ○ la détermination (E70) d'une séquence ordonnée de commandes permettant de transférer des données entre la première et la deuxième page au moyen d'une mémoire tampon du dispositif ; et ○ la mise à jour (E80) de la version courante du graphe pour refléter les transferts de données ; - la génération (E40) d'instructions à partir des commandes déterminées.

Description

Arrière-plan de l'invention
L'invention se rapporte au domaine général de l'informatique et concerne plus particulièrement la mise à jour « sur place » (ou « in-place » en anglais) d'un fichier de données tel un logiciel par un dispositif.
L'avènement de l'Internet des Objets a créé de nouveaux défis en termes de maintenance et de mise à jour de grandes constellations d'objets connectés à Internet, auxquels l'accès physique peut qui plus est, s'avérer compliqué et limité. Pour des raisons de coût et d'autonomie notamment, les composants logiciels et matériels équipant ces objets se prêtent mal aux opérations de maintenance utilisées pour des ordinateurs classiques et présentent un certain nombre de contraintes dont il est nécessaire de tenir compte.
Ainsi, par exemple, les sources d'énergie de ces objets n'étant pas facilement remplaçâmes, il est critique lors d'une intervention sur ces objets de minimiser les opérations coûteuses en énergie, telles que par exemple le transfert de données.
En outre, en raison de la dimension des parcs d'objets concernés, lorsqu'une mise à jour d'un logiciel équipant ces objets est envisagée au moyen d'un patch ou autre, le format du patch utilisé peut avoir un effet important sur la vitesse de mise à jour (par exemple, du fait d'un nombre de connexions instantanées requises au serveur de mise à jour).
La technologie de stockage la plus couramment utilisée sur ce type d'objets est une mémoire persistante ou non volatile telle qu'une mémoire flash de type NAND, qui ne requiert pas d'alimentation électrique pour conserver ses données. Ce type de mémoire n'offre pas la possibilité de pouvoir modifier les données qu'elle contient au niveau de l'octet ni même du mot, mais oblige à manipuler des blocs individuels de données de taille plus importante, aussi désignée par « pages » ou « secteurs » de données, telle que par exemple de 4096 octets. En outre, toute écriture sur une page d'une mémoire NAND requiert d'effacer préalablement le contenu de cette page.
On comprend bien dès lors, au vu de ces nombreuses contraintes, que la mise à jour des logiciels équipant de tels objets connectés est une opération critique qui nécessite d'être optimisée.
Une approche efficace connue pour procéder à une telle mise à jour consiste à transmettre à l'objet connecté concerné uniquement les différences entre l'ancienne version du logiciel (c'est-à-dire du fichier de données implémentant le logiciel) et la nouvelle version du logiciel. Ces différences sont répertoriées dans un fichier de données connu sous le nom de « fichier delta » qui se présente sous la forme d'une suite d'instructions reflétant les changements entre l'ancienne et la nouvelle version du logiciel.
Il n'est pas rare que les objets connectés ne disposent pas de suffisamment d'espace mémoire pour combiner l'ancienne version du logiciel avec le fichier delta dans une nouvelle version stockée séparément de l'ancienne version. Il est donc souvent nécessaire, pour ces objets connectés, de réaliser une mise à jour dite « sur place » ou « in-place » en anglais, qui consiste à construire la nouvelle version du logiciel dans le même espace mémoire que l'ancienne version.
Lorsqu'une mise à jour sur place d'un fichier de données ou d'un logiciel est envisagée, des conflits peuvent apparaître du fait que certaines données se trouvant à un endroit donné dans l'ancienne version du fichier de données doivent être effacées et remplacées par de nouvelles données lors de la mise à jour avant même d'avoir pu être lues et écrites à un autre endroit dans la nouvelle version du fichier.
Un premier exemple d'un tel conflit est présenté dans la table ci-dessous.
Adresse mémoire 0x1000 0x2000 0x3000 0x4000 0x5000 0x6000 0x7000 0x8000
Ancienne version A B C D E F G H
Nouvelle version A B F D E C G H
Chaque lettre dans la table (A, B, C,...) désigne un ensemble de données se trouvant à l'adresse mémoire considérée (i.e. sur la page se trouvant à l'adresse 0x1000, sur la page se trouvant à l'adresse 0x2000, etc.). Dans l'exemple illustré, la nouvelle version du logiciel requiert :
— une copie de l'ensemble de données C, présent dans l'ancienne version du logiciel sur la page se trouvant à l'adresse mémoire 0x3000, sur la page se trouvant à l'adresse mémoire 0x6000 et occupée dans l'ancienne version par l'ensemble de données F ; et — une copie de l'ensemble de données F sur la page se trouvant à l'adresse mémoire 0x3000 et occupée dans l'ancienne version par l'ensemble de données C.
Il existe donc un conflit entre la copie de l'ensemble de données C de la page se trouvant à l'adresse 0x3000 vers la page se trouvant à l'adresse 0x6000 et la copie de F de la page se trouvant à l'adresse 0x6000 vers la page se trouvant à l'adresse 0x3000, car une fois que l'ensemble de données F sera copié sur la page se trouvant à l'adresse 0x3000 (c'est-à-dire potentiellement à la place de l'ensemble de données C), il deviendra impossible de copier l'ensemble de données C initialement présent sur la page se trouvant à l'adresse 0x3000 sur la page se trouvant à l'adresse 0x6000, si cet ensemble de données a été précédemment effacé pour permettre la copie de l'ensemble F sur la page se trouvant à l'adresse 0x3000.
Certains conflits peuvent être résolus de façon triviale. C'est le cas notamment du deuxième exemple de conflit exposé dans la table ci-dessous·
Adresse mémoire 0x1000 0x2000 0x3000 0x4000 0x5000 0x6000 0x7000 0x8000
Ancienne version A B C D E F G H
Nouvelle version A B C F E C G H
Pour gérer ce conflit, il suffit en effet d'exécuter en premier la copie de l'ensemble de données F à l'adresse 0x4000 puis de copier l'ensemble de données C à l'adresse 0x6000 occupée dans l'ancienne version du fichier de données par l'ensemble de données F.
Toutefois, pour gérer le premier exemple de conflit, un simple ordonnancement approprié des opérations d'écriture et de lecture n'est pas suffisant. Une solution possible consiste à intégrer dans le fichier delta l'ensemble de données C ou l'ensemble de données F, et ce, malgré la présence de ces deux ensembles de données dans l'ancienne version du fichier de données à mettre à jour. Le fichier delta inclut alors deux types d'instructions pour distinguer les opérations de mise à jour consistant à ajouter de nouvelles données à l'ancienne version (instructions « ADD ») des opérations de mise à jour consistant à copier des données existant dans l'ancienne version (instructions « COPY »). Une telle solution est décrite par exemple dans le document US 6 018 747.
Une autre solution pour gérer le premier exemple de conflit est de charger dans une mémoire tampon de l'objet connecté (mémoire dynamique) le contenu de l'une des pages de données affectées, par exemple celle se trouvant à l'emplacement 0x3000, avant de l'effacer et de copier à sa place l'ensemble de données F. Une fois copié à l'adresse mémoire 0x3000, l'ensemble de données F peut être à son tour effacé, et l'ensemble de données C chargé dans la mémoire tampon peut être recopié à l'adresse mémoire 0x6000. Il convient de noter que la mémoire dynamique est plus coûteuse que la mémoire persistante et que les objets connectés en disposent de ce fait généralement assez peu (typiquement de quoi stocker au maximum quelques pages de données). Par conséquent, si une telle solution peut être envisagée pour gérer des conflits affectant deux pages de données, elle semble difficilement envisageable pour des conflits cycliques plus complexes ou pour des réseaux de conflits. On parle de réseau de conflits lorsque, pour mettre le fichier à jour, de multiples copies doivent être réalisées vers de multiples pages créant des situations de conflit telles que présentées ci-avant, mais sans nécessairement suivre un motif particulier. Ainsi, la notion de réseau de conflits intègre les conflits cycliques, mais également des conflits plus complexes comme par exemple des conflits susceptibles de se présenter dans une situation où une multitude de copies bidirectionnelles entre de multiples pages doit être mise en œuvre pour mettre à jour un fichier.
Un exemple d'un conflit cyclique plus complexe est illustré dans la table ci-dessous.
Adresse mémoire 0x1000 0x2000 0x3000 0x4000 0x5000 0x6000 0x7000 0x8000
Ancienne version A B C D E F G H
Nouvelle version H A B C D E F G
Pour gérer ce conflit cyclique en utilisant la solution alternative présentée ci-avant, une mémoire tampon de dimension équivalente à une page de données n'est pas suffisante. Il faut recourir à une mémoire tampon ayant au moins le double de cette taille ce qui peut s'avérer impossible ou inapproprié dans le contexte de certains objets connectés.
Il en est de même en cas d'existence d'un réseau de conflits : de manière générale, celui-ci ne peut être réduit à une série de conflits chaînés, et la quantité de données à stocker dans la mémoire tampon peut s'avérer prohibitive pour un objet connecté.
Le document WO 2007/023497 présente une solution s'appuyant sur la copie dans une mémoire de protection de l'objet opérant la mise à jour, d'ensembles de données susceptibles d'être à l'origine de conflits afin de ne pas perdre d'information lorsque ces ensembles de données sont manipulés lors de la mise à jour. Toutefois, suivant la configuration des conflits à gérer, cette solution peut requérir une mémoire de protection de taille importante qui, de plus, n'est pas déterministe, autrement dit qui peut varier d'une configuration de conflits à l'autre. Ceci peut s'avérer compliqué à gérer au niveau d'un objet connecté.
Objet et résumé de l'invention
L'invention propose une solution alternative aux solutions de l'état de la technique permettant de gérer des réseaux de conflits et ne présentant pas les inconvénients précités de l'état de la technique.
Plus précisément, l'invention vise un procédé de génération d'un ensemble d'instructions destinées à un dispositif pour mettre à jour sur place une version initiale d'un fichier de données en une version finale, ce fichier étant stocké sous la forme d'une pluralité de pages d'une taille prédéterminée dans une mémoire persistante du dispositif, le procédé de génération comprenant :
— une étape d'initialisation d'une version courante d'un graphe comprenant une pluralité de nœuds et d'arcs orientés et dans lequel chaque nœud représente une page distincte de la mémoire persistante occupée par le fichier, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à un ensemble de données contenu dans la page représentée par le nœud de départ devant être transféré vers la page représentée par le nœud de destination pour obtenir la version finale du fichier ;
— tant que la version courante du graphe comprend au moins un arc orienté, une itération de traitement comprenant :
o une étape de sélection dans la version courante du graphe d'un premier arc orienté allant d'un premier nœud représentant une première page vers un deuxième nœud représentant une deuxième page ;
o une étape de détermination d'une séquence ordonnée de commandes qui permet, au moyen d'une mémoire tampon :
de transférer l'ensemble de données associé au premier arc orienté vers la deuxième page, et si un deuxième arc orienté allant du deuxième nœud vers le premier nœud existe, de transférer vers la première page, au moins une partie de l'ensemble de données associé à ce deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données, et s'il existe au moins un troisième arc orienté allant du premier ou du deuxième nœud vers un troisième nœud distinct du premier et du deuxième nœud, de répartir ledit au moins un ensemble de données associé audit au moins un troisième arc entre la première page et/ou la deuxième page ;
o une étape de mise à jour de la version courante du graphe de sorte à refléter les transferts et la répartition des ensembles de données considérés lors de l'étape de détermination ;
— une étape de génération dudit ensemble d'instructions à partir des séquences ordonnées de commandes déterminées lors des itérations de traitement.
Corrélativement, l'invention concerne également un dispositif de génération d'un ensemble d'instructions destinées à un autre dispositif pour mettre à jour sur place une version initiale d'un fichier de données en une version finale, ce fichier étant stocké sous la forme d'une pluralité de pages d'une taille prédéterminée dans une mémoire persistante dudit autre dispositif, le dispositif de génération comprenant :
— un module d'initialisation, configuré pour initialiser une version courante d'un graphe comprenant une pluralité de nœuds et d'arcs orientés et dans lequel chaque nœud représente une page distincte de la mémoire persistante occupée par le fichier, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à un ensemble de données contenu dans la page représentée par le nœud de départ devant être transféré vers la page représentée par le nœud de destination pour obtenir la version finale du fichier ;
— un module de traitement itératif, activé tant que la version courante du graphe comprend au moins un arc orienté, ledit module comprenant un module de sélection, un module de détermination et un module de mise à jour activés lors de chaque itération de traitement tels que :
o le module de sélection est configuré pour sélectionner dans la version courante du graphe un premier arc orienté allant d'un premier nœud représentant une première page vers un deuxième nœud représentant une deuxième page ;
o le module de détermination est configuré pour déterminer une séquence ordonnée de commandes qui permet, au moyen d'une mémoire tampon :
- de transférer l'ensemble de données associé au premier arc orienté vers la deuxième page, et si un deuxième arc orienté allant du deuxième nœud vers le premier nœud existe, de transférer vers la première page, au moins une partie de l'ensemble de données associé à ce deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données, et s'il existe au moins un troisième arc orienté allant du premier ou du deuxième nœud vers un troisième nœud distinct du premier et du deuxième nœud, de répartir ledit au moins un ensemble de données associé audit au moins un troisième arc entre la première page et/ou la deuxième page ;
o le module de mise à jour est configuré pour mettre à jour la version courante du graphe de sorte à refléter les transferts et la répartition des ensembles de données considérés par le module de détermination ;
— un module de génération, configuré pour générer ledit ensemble d'instructions à partir des séquences ordonnées de commandes déterminées lors des itérations de traitement.
Selon un autre aspect, l'invention vise aussi un procédé de mise à jour sur place par un dispositif, d'une version initiale d'un fichier de données en une version finale, ce fichier étant stocké sous la forme d'une pluralité de pages d'une taille prédéterminée dans une mémoire persistante du dispositif, le procédé de mise à jour comprenant :
— une étape d'obtention d'un ensemble d'instructions générées en utilisant un procédé de génération selon l'invention et d'un fichier delta comprenant une pluralité d'instructions conduisant à la version finale du fichier de données ;
— une étape de génération d'une pré-image de la version finale du fichier de données en appliquant ledit ensemble d'instructions à la version initiale du fichier de données ; et — une étape d'application d'instructions du fichier delta à la pré-image générée.
Corrélativement, l'invention concerne un dispositif de mise à jour comprenant une mémoire persistante dans laquelle est stockée une version initiale d'un fichier de données sous la forme d'une pluralité de pages d'une taille prédéterminée, ledit dispositif de mise à jour comprenant :
— un module d'obtention, apte à obtenir un ensemble d'instructions générées par un dispositif de génération selon l'invention et un fichier delta comprenant une pluralité d'instructions conduisant à la version finale du fichier de données ;
— un module de génération configuré pour générer une pré-image de la version finale du fichier de données en appliquant ledit ensemble d'instructions à la version initiale du fichier de données ; et — un module d'application, configuré pour appliquer des instructions du fichier delta à la préimage générée et obtenir la version finale du fichier de données.
Le dispositif de génération et le dispositif de mise à jour sont préférentiellement des dispositifs distincts. A titre illustratif, le dispositif de génération peut être un serveur tandis que le dispositif de mise à jour peut être n'importe un objet connecté disposant de ressources plus limitées (notamment concernant ses ressources mémoire). Toutefois aucune limitation n'est attachée à la nature des dispositifs auxquels s'applique l'invention.
Ainsi, l'invention propose un procédé itératif permettant de générer des instructions destinées au dispositif ou à l'objet effectuant la mise à jour sur place du fichier de données, afin de lui permettre de gérer plus facilement la présence d'un réseau de conflits apparaissant lors de cette mise à jour, et ce, en utilisant une mémoire tampon de dimension déterministe qui ne dépasse pas la taille d'une page de données. Par mémoire tampon, on entend ici une petite zone de mémoire qui peut être notamment dynamique (ex. RAM pour Random Access Memory) par opposition à la mémoire persistante dans laquelle est stockée le fichier de données sur le dispositif ayant besoin de réaliser une mise à jour.
On note que l'invention s'applique quelle que soit la nature du réseau de conflits : il peut s'agir d'un conflit cyclique comme d'un ensemble de conflits résultant de multiples copies (bidirectionnelles ou non) vers de multiples pages qui ne présentent pas de motif ou de structure particulier(ère).
Grâce aux instructions générées par le dispositif de génération selon l'invention (qui est distinct préférentiellement du dispositif effectuant la mise à jour), la complexité des opérations réalisées par le dispositif lors de la mise à jour sur place peut être grandement réduite. L'exécution des instructions générées par le dispositif de génération permet en effet au dispositif de mise à jour d'obtenir une pré-image de la version finale du fichier de données dans laquelle tous les ensembles de données destinées à être transférés d'une page à une autre entre la version initiale du fichier et sa version finale se trouvent dans la page dans laquelle ils doivent se trouver dans la version finale du fichier. En d'autres mots, la pré-image est exempte de conflits, ceux-ci ayant été résolus en amont par le dispositif de génération au cours des itérations de traitement du procédé de génération. On note que des réorganisations des données au sein de chaque page de la préimage peuvent être nécessaires (c'est l'objet notamment du fichier delta), mais celles-ci étant effectuées au sein d'une seule page, elles peuvent être aisément gérées par le dispositif de mise à jour au moyen par exemple en chargeant la page en question dans la mémoire tampon.
Conformément à l'invention, le dispositif de génération a avantageusement dérivé de cette résolution un ensemble d'instructions destinées à être appliquées directement par le dispositif de mise à jour à partir de la version initiale du fichier pour obtenir la pré-image : le dispositif de mise à jour n'a de cette sorte aucun conflit à gérer pour mettre à jour sur place le fichier de données et n'a qu'à exécuter les instructions qui lui sont transmises. Le passage de la pré-image à la version finale du fichier peut alors être réalisé au moyen d'un simple fichier delta.
On note que les instructions générées par le dispositif de génération peuvent être transmises dans un fichier d'instructions distinct du fichier delta ou être insérées dans celui-ci.
Pour la génération des instructions, l'invention s'appuie sur une modélisation sous forme d'un graphe orienté des modifications devant être effectuées pour obtenir la version finale du fichier de données : chaque nœud du graphe représente une page distincte de la mémoire persistante du dispositif de mise à jour occupée par le fichier, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à un ensemble de données contenu dans la page représentée par le nœud de départ devant être transféré vers la page représentée par le nœud de destination pour obtenir la version finale du fichier. A la première itération, on initialise la version courante du graphe à partir du contenu des pages de la version initiale du fichier.
Puis, une pluralité d'itérations dites de traitement sont mises à en œuvre pour traiter les différents arcs orientés du graphe : des itérations sont mises en œuvre tant qu'il existe un arc orienté dans la version mise à jour du graphe. Lors de chaque itération de traitement, un arc orienté de la version courante du graphe est sélectionné, et des transferts de données judicieusement choisis sont envisagés entre les pages correspondant au nœud de départ et de destination de l'arc sélectionné visant à supprimer cet arc du graphe. Autrement dit, à l'issue d'une itération, la version courante du graphe mise à jour ne contient plus l'arc sélectionné : toutes les données présentes dans la page correspondant au nœud de départ et destinées au nœud de destination ont ainsi été transférées vers ce dernier (et inversement) tout en évitant habilement la perte de données. En outre, toutes les données destinées à d'autres pages ont été préservées dans les deux pages pour un transfert ultérieur.
Pour mettre en œuvre les transferts et la répartition des ensembles de données envisagés par le dispositif de génération, une mémoire tampon ayant une taille égale à la taille prédéterminée d'une page est avantageusement suffisante sur le dispositif de mise à jour. Elle permet au premier nœud et au deuxième nœud d'échanger leurs données tout en se rapprochant de la configuration des première et deuxième page de la version finale du fichier.
Ainsi à titre d'exemple, dans un mode particulier de réalisation, lors de l'étape de détermination, la séquence ordonnée de commandes peut comprendre :
— une première commande de stockage, dans la mémoire tampon du dispositif, du contenu de la deuxième page représenté par le deuxième nœud ;
— une première commande d'écriture sur la deuxième page, depuis la mémoire tampon et la première page, des données contenues dans la deuxième page représentée par le deuxième nœud et présentes dans la deuxième page de la version finale du fichier, de l'ensemble de données associé au premier arc orienté et des ensembles de données associés audit au moins un troisième arc répartis sur la deuxième page;
— une deuxième commande de stockage, dans la mémoire tampon, des ensembles de données contenus dans la première page représentée par le premier nœud à l'exception des ensembles de données écrits via la première commande d'écriture sur la deuxième page et en conservant dans la mémoire tampon les ensembles de données stockés via la première commande de stockage devant être transférés vers la première page ; et — une deuxième commande d'écriture, sur la première page, depuis la mémoire tampon, des données contenues dans la première page représentée par le premier nœud et présentes dans la première page de la version finale du fichier, d'au moins une partie de l'ensemble de données associé au deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données et des ensembles de données associés audit au moins un troisième arc répartis sur la première page.
La deuxième commande de stockage peut exploiter si besoin (i.e. écrire dans) l'espace de la mémoire tampon contenant les données déjà écrites, via la première commande d'écriture, sur la deuxième page. Toutes les données nécessaires à la deuxième commande d'écriture ont la place d'être stockées dans la mémoire tampon puisque par définition de ces données, elles ont été attribuées à la première page et peuvent donc être contenues dans une page et a fortiori dans la mémoire tampon d'une page.
Bien entendu cet exemple de séquence ordonnée de commandes n'est donné qu'à titre illustratif et d'autres séquences de commandes peuvent être envisagées pour aboutir au même résultat. Par exemple, la séquence de commandes peut inclure avant chaque écriture sur une page l'effacement de cette page.
A l'issue d'une itération de traitement, comme mentionné précédemment, toutes les données devant être transférées de la première page vers la deuxième page de données l'ont été de sorte qu'il n'existe plus dans le graphe d'arc orienté allant du premier nœud vers le deuxième nœud (voire dans certains cas de figure d'arc orienté allant du deuxième nœud vers le premier nœud lorsque l'ensemble de données associé à cet arc peut être transféré vers le premier nœud). Ceci est reflété par la mise à jour de la version courante du graphe (qui peut consister typiquement en une mise à jour de métadonnées associées aux nœuds du graphe et aux arcs du graphe décrivant les ensembles de données impliquées par et entre les pages du fichier), qui est ensuite utilisée à l'itération suivante. Le réseau de conflits est ainsi géré au fil de chaque itération jusqu'à sa résolution complète.
Les commandes obtenues lors de chaque itération mise en œuvre durant l'étape de traitement pour gérer le réseau de conflits sont ensuite transformées en un ensemble d'instructions destinées à être fournies et appliquées par le dispositif réalisant la mise à jour sur place de la version initiale du fichier de données : suite à l'application de ces instructions, le dispositif obtient une pré-image du fichier de données exempte de conflits sur laquelle il peut aisément appliquer un fichier delta relativement simplifié qui comprend tout au plus que des déplacements de données au sein d'une même page.
Chaque commande obtenue lors d'une itération peut être traduite en une ou plusieurs instructions destinées au dispositif effectuant la mise à jour. On peut également envisager, dans un but d'optimisation, que plusieurs commandes soient regroupées et fassent l'objet d'instructions communes, notamment si elles sont redondantes d'une itération à l'autre, et ce, afin de diminuer le nombre d'opérations à réaliser par le dispositif lors de la mise à jour sur place du fichier de données. Une telle faculté peut être offerte en sélectionnant par exemple de façon astucieuse les arcs considérés lors de chaque itération.
D'autres façons d'optimiser les instructions générées peuvent être envisagées, notamment au niveau du codage de ces instructions.
A titre illustratif, dans un mode particulier de réalisation, l'ensemble d'instructions peut comprendre au moins une instruction parmi :
— une instruction de copie de données d'une page de la mémoire persistante vers la mémoire tampon ;
— une instruction de copie de données de la mémoire tampon vers une page de la mémoire persistante ;
— une instruction de copie de données de la mémoire tampon vers la mémoire tampon ;
— une instruction d'effacement de données de la mémoire persistante ;
— une instruction de désignation d'une page de la mémoire persistante ;
— une instruction de copie chaînée de données de la mémoire persistante vers la mémoire persistante ou la mémoire tampon ;
— une instruction de copie chaînée de données de la mémoire tampon vers la mémoire persistante ou la mémoire tampon.
L'instruction de désignation d'une page de la mémoire persistante peut être utilisée par exemple pour signaler au dispositif que les instructions suivant cette instruction de désignation vont porter sur une même page (celle désignée par l'instruction de désignation) et s'affranchir dans lesdites instructions suivantes de coder la page en question. Il est ainsi possible de gagner quelques bits dans le codage des instructions.
De façon similaire, les instructions de copie étant coûteuses à coder (il est nécessaire notamment de coder les adresses de départ et de destination, ainsi que la longueur de la copie), les instructions de copie chaînée permettent de s'affranchir du codage de l'adresse de destination lorsque les données à copier sont à copier à la suite les unes des autres.
Bien entendu ces exemples d'instructions ne sont donnés qu'à titre illustratif et d'autres instructions peuvent être envisagées pour optimiser encore davantage le codage des instructions transmises au dispositif.
Dans un autre mode de réalisation, lors d'une itération de traitement, le premier arc orienté est sélectionné de façon aléatoire.
Aucune limitation n'est attachée à la façon dont ce premier arc est sélectionné : une simple sélection aléatoire peut être envisagée ou en variante, des heuristiques permettant d'optimiser le traitement effectué lors de chaque itération de traitement et le nombre d'itérations de traitement nécessaire pour résoudre le réseau de conflits peuvent être élaborées et utilisées.
Ainsi, par exemple, si une taille de l'ensemble de données associé au premier arc orienté sélectionné est supérieure à une somme des tailles des ensembles de données associés aux arcs orientés partant du deuxième nœud, ladite itération de traitement comprend, en remplacement des étapes de détermination et de mise à jour :
— une étape de détermination d'une séquence ordonnée de commandes qui permet, au moyen de ladite mémoire tampon :
o de transférer vers la deuxième page, de chaque ensemble de données associé à un arc orienté de la version courante du graphe arrivant sur le deuxième nœud ; et o de transférer vers la première page, de chaque ensemble de données associé à un arc orienté de la version courante du graphe partant du deuxième nœud ;
— une étape de mise à jour de la version courante du graphe de sorte à refléter les transferts considérés lors de l'étape de détermination.
Autrement dit, si l'arc sélectionné présente certaines propriétés (ou plus précisément l'ensemble de données associé à cet arc), l'invention propose d'optimiser le traitement opéré lors de l'itération de traitement conduisant à l'élimination d'un nœud du réseau de conflits modélisé par le graphe (en l'espèce le deuxième nœud).
Dans un mode particulier de réalisation, la séquence ordonnée de commandes reflétant un tel traitement comprend :
— une première commande de stockage, dans la mémoire tampon du dispositif, du contenu de la deuxième page représentée par le deuxième nœud ;
— une première commande d'écriture sur la deuxième page, depuis la mémoire tampon et les pages représentées par les nœuds de départ des arcs orientés arrivant sur le deuxième nœud, des ensembles de données associés à ces arcs et des données contenues dans la deuxième page représentée par le deuxième nœud et présentes dans la deuxième page de la version finale du fichier ;
— une deuxième commande de stockage, dans la mémoire tampon, des ensembles de données contenus dans la première page représentée par le premier nœud à l'exception de l'ensemble de données associé au premier arc orienté ;
— une deuxième commande d'écriture sur la première page, depuis la mémoire tampon, des données contenues dans la première page représentée par le premier nœud et présentes dans la première page de la version finale du fichier, de l'ensemble de données associé au deuxième arc orienté et des ensembles de données associés aux arcs orientés partant du deuxième nœud.
Ainsi, des heuristiques de sélection de l'arc lors de chaque itération de traitement peuvent être élaborées pour favoriser les traitements optimisés décrits ci-dessus lorsque cela est possible. On note toutefois que lorsque le réseau de conflits est quelconque et ne présente pas de motif particulier, il n'est pas toujours possible de sélectionner des arcs présentant les propriétés énoncées ci-dessus.
On peut également envisager une heuristique de sélection des arcs qui favorise la sélection d'un arc entre deux nœuds du graphe liés par un lien « bidirectionnel », qui permet de gérer au cours d'une même itération de traitement le transfert de données compris dans la première page vers la deuxième page et le transfert de données compris dans la deuxième page vers la première page.
Dans un mode particulier de réalisation, le procédé de génération comprend, lors de l'étape de détermination, pour répartir ledit au moins un ensemble de données associé audit au moins un troisième arc :
— une étape d'attribution dans l'ordre décroissant de leur taille, chaque ensemble dudit au moins un ensemble de données à l'une des pages parmi la première et la deuxième page tant que celle-ci contient suffisamment de place pour contenir lesdits ensembles de données qui lui sont attribués dans leur intégralité ;
— une étape d'attribution des ensembles de données restant à l'autre page parmi la première et la deuxième page tant que celle-ci contient suffisamment de place pour contenir lesdits ensembles de données restant dans leur intégralité ; et — s'il reste un ensemble de données non attribué, une étape de répartition du contenu de cet ensemble de données entre la première page et la deuxième page.
Cette façon de répartir les ensembles de données devant être transférés depuis la première page et la deuxième page vers d'autres pages du fichier de données permet de favoriser le stockage des ensembles de données « entiers » dans la première page et la deuxième page. En procédant de la sorte, au plus un ensemble de données risque d'être fractionné entre la première page et la deuxième page.
En outre, si l'une des pages correspondant au premier nœud ou au deuxième nœud contient suffisamment d'espace disponible pour stocker toutes les ensembles de données destinés à des nœuds tiers, elle se voit attribuer tous ces ensembles de données ce qui permet de sortir le nœud associé à l'autre page du réseau de conflits lors de l'itération et donc de simplifier les traitements ultérieurs à réaliser.
Dans un mode particulier de réalisation, le procédé de génération comprend lors de l'étape de détermination, pour répartir ledit au moins un ensemble de données associé audit au moins un troisième arc, s'il existe dans le graphe deux arcs orienté allant respectivement du premier et du deuxième nœud vers un même troisième nœud, une étape d'agrégation au sein d'un même ensemble de données des ensembles de données associés auxdits arcs, avant de répartir ledit ensemble de données agrégés entre la première page et/ou la deuxième page.
Cette étape d'agrégation permet d'optimiser encore davantage le traitement du réseau de conflits et de simplifier les échanges de données à envisager lors des itérations de traitement suivantes.
Dans un mode particulier de réalisation, les différentes étapes du procédé de génération et/ou du procédé de mise à jour sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre respectivement dans un dispositif de génération ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de génération tel que décrit cidessus. L'invention concerne également un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre respectivement dans un dispositif de mise à jour ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de mise à jour tel que décrit ci-dessus.
Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné cidessus.
Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple un disque dur.
D'autre part, le support d'informations ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise également un système comprenant :
— un dispositif de mise à jour selon l'invention, stockant dans une mémoire persistante un fichier de données dans une version initiale sous la forme d'une pluralité de pages d'une taille prédéterminée ; et — un dispositif de génération selon l'invention, configuré pour générer un ensemble d'instructions destinées au dispositif de mise à jour pour mettre à jour sur place la version initiale du fichier de données en une version finale.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de génération, le dispositif de génération, le procédé de mise à jour, le dispositif de mise à jour et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— la figure 1 représente, dans son environnement, un système comprenant un dispositif de mise à jour et un dispositif de génération conformes à l'invention dans un mode particulier de réalisation ;
— la figure 2 représente un exemple d'architecture matérielle du dispositif de génération de la figure 1 ;
— la figure 3 représente un exemple d'architecture matérielle du dispositif de mise à jour de la figure 1 ;
— la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de génération selon l'invention ;
— la figure 5 illustre sur un exemple la version courante du graphe utilisée lors de la première itération du procédé de génération de la figure 4 ;
— la figure 6 illustre la démarche adoptée par le dispositif de génération pour déterminer un ensemble de commandes à partir de la version courante du graphe illustrée à la figure 5 ;
— les figures 7A, 7B illustrent différentes mises à jour possibles de la version courante du graphe illustré à la figure 5 ; et — la figure 8 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de mise à jour selon l'invention.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système 1 comprenant un dispositif 2 équipé d'un logiciel ou fichier de données LOG, stocké dans une mémoire persistante ou non volatile 3 du dispositif 2, et pour lequel on envisage une mise à jour. La mémoire persistante 3 est par exemple une mémoire flash NAND connue en soi.
Le dispositif 2 est un dispositif de mise à jour conforme à l'invention. Dans l'exemple illustré à la figure 1, le dispositif 2 est un objet connecté à Internet, tel que par exemple un capteur, un détecteur, une montre, etc. Toutefois, aucune limitation n'est attachée à la nature du dispositif 2, il peut s'agir par exemple de tout type d'objet communiquant susceptible d'échanger des données avec un autre dispositif, via une interface de communication telle que par exemple une interface de communication sans fil.
Dans l'exemple envisagé ici, on suppose que le dispositif 2 dispose de ressources mémoire limitées, de sorte qu'une mise à jour du fichier de données LOG « sur place » est envisagée. Pour rappel, lors d'une telle mise à jour, la version finale Vfin du fichier de données (c'est-à-dire obtenue après mise à jour) est stockée au même emplacement dans la mémoire persistante 3 que la version initiale Vinit du fichier de données avant mise à jour. Le dispositif 2 utilise à cet effet un fichier delta, noté Fû, complété par des instructions générées conformément à l'invention, comme décrit plus en détail ultérieurement.
On suppose ici, que le fichier de données LOG occupe dans la mémoire persistante 3 une pluralité de pages de données d'une même taille prédéterminée, par exemple de taille égale à 4096 octets. Une page de données représente dans le contexte de l'invention la plus petite quantité de données ordonnées et contiguës que l'objet connecté 2 peut effacer de sa mémoire.
On suppose par ailleurs que la mise à jour du fichier de données LOG que doit réaliser l'objet connecté 2 présente un réseau de conflits entre plusieurs pages de données du fichier de données LOG, comme décrit précédemment. Ce réseau de conflits peut être identifié en analysant un fichier delta dit initial, FAO, contenant les instructions reflétant les changements devant être opérés entre la version initiale Vinit du fichier de données LOG et sa version finale Vfin. Un tel fichier delta est connu en soi et n'est pas décrit davantage ici.
A titre illustratif seulement, on envisage le réseau de conflit représenté dans la table 1 reproduite ci-dessous :
Adresse mémoire de la page PI : 0x1000 P2 : 0x2000 P3 : 0x3000 P4 : 0x4000
Ensembles de données contenues dans la version initiale du fichier LOG A-B-C-D E-F-G-H I-J-K-L M-N-O-P
Ensembles de données requises dans chaque page de la version finale du fichier LOG (préimage de la version finale) A-E-I-M B-F-J-N C-G-K-0 D-H-L-P
Dans l'exemple illustré ci-dessus, les ensembles de données A-P constituent des ensembles de données de dimension quelconque compris dans quatre pages PI, P2, P3 et P4 de la version initiale Vinit du fichier de données LOG et susceptibles d'être déplacés vers d'autres pages dans la version finale Vfin du fichier LOG après mise à jour. De manière générale, ces ensembles de données peuvent avoir des tailles différentes ou identiques ; par ailleurs les ensembles de données contenus dans une même page peuvent être disjoints ou avoir des données en commun. Par souci de simplification, on suppose dans l'exemple envisagé que les ensembles de données associés à une même page désignent des ensembles de données disjoints deux à deux (par exemple, les ensembles de données A, B, C, et D sont disjoints deux à deux).
Ainsi, selon l'exemple donné dans la table 1, la page PI de la version initiale Vinit du fichier LOG contient quatre ensembles de données A-B-C-D. Dans la version finale du fichier LOG, l'ensemble A reste sur la page PI (mais pas nécessairement au même emplacement que dans la version initiale), B est déplacé vers la page P2, C est déplacé vers la page P3 et D est déplacé vers la page P4. De façon similaire, les ensembles E, I, M contenus dans la version initiale Vinit dans les pages P2, P3 et P4 respectivement, viennent compléter l'ensemble A sur la page PI dans la version finale du fichier LOG. La table 1 ne présume pas d'un ordre particulier des ensembles de données dans la version finale du fichier LOG. Elle ne fait que résumer les échanges de données qui sont nécessaires entre les pages du fichier LOG pour former la version finale du fichier LOG.
La troisième ligne de la table 1 offre ainsi une « pré-image » de la version finale du fichier LOG : il s'agit d'une version du fichier LOG dans laquelle les ensembles de données qui doivent être déplacés lors de la mise à jour vers d'autres pages que les pages dans lesquels ils sont contenus dans la version initiale Vinit, se trouvent dans leur page de destination, mais pas nécessairement dans le bon ordre. Autrement dit, les données nécessaires à la constitution de la version finale du fichier LOG se trouvent dans cette pré-image dans les bonnes pages mais peuvent nécessiter d'être réorganisées, via le fichier delta, pour se conformer à la version finale attendue.
Bien entendu, cet exemple n'est donné qu'à titre illustratif et n'est aucunement limitatif de l'invention.
L'invention, par le biais des instructions générées, vise comme détaillé ultérieurement à permettre au dispositif 2 d'obtenir cette pré-image en vue de faciliter la mise à jour sur place du fichier de données LOG par l'objet connecté 2. Ces instructions sont générées par un dispositif de génération 4 d'instructions, conforme à l'invention, compris dans le système 1.
Dans le mode de réalisation décrit ici, le dispositif de génération 4 est par exemple un serveur ou un ordinateur disposant de l'architecture matérielle illustrée à la figure 2. Il comprend notamment un processeur 5, une mémoire non volatile 6, une mémoire vive 7, ainsi que des moyens de communication 8. Ces moyens de communication 8 permettent au dispositif de génération 4 de communiquer notamment avec l'objet connecté 2 pour lui fournir les instructions qu'il a générées pour faciliter la mise à jour sur place du fichier logiciel LOG. Ils peuvent comprendre par exemple une interface de communication sans fil, telle qu'une interface Bluetooth ou WiFI ou cellulaire (ex. 3G, 4G, ou 5G).
La mémoire non volatile 6 du dispositif de génération 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 5 et sur lequel est enregistré un programme d'ordinateur PROG4 conforme à l'invention, comportant des instructions pour l'exécution d'un procédé de génération selon l'invention.
Le programme PROG4 définit divers modules fonctionnels et logiciels ici du dispositif de génération 4, aptes à mettre en œuvre les étapes du procédé de génération selon l'invention et s'appuyant sur les éléments matériels 5-8 du dispositif de génération 4. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré à la figure 1 :
— un module 4A de traitement itératif, comportant un module d'initialisation 4A1, configuré pour initialiser une version courante G d'un graphe orienté comprenant une pluralité de nœuds et d'arcs orientés et dans lequel chaque nœud représente une page distincte de la mémoire persistante occupée par le fichier LOG, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à un ensemble de données contenu dans la page représentée par le nœud de départ devant être transféré vers la page représentée par le nœud de destination pour obtenir la version finale du fichier. Lors de l'initialisation, les pages représentées par les nœuds correspondent aux pages de la version initiale Vinit du fichier. Le module de traitement 4A comprend également une pluralité de modules 4A2 à 4A4, activés au cours d'une pluralité d'itérations de traitement du procédé de génération selon l'invention et comprenant :
o un premier module 4A2 de sélection, configuré pour sélectionner dans la version courante G du graphe, un premier arc orienté allant d'un premier nœud représentant une première page vers un deuxième nœud représentant une deuxième page ;
o un module 4A3 de détermination, configuré pour déterminer une séquence ordonnée de commandes qui permet, au moyen d'une mémoire tampon BUF de l'objet 2 :
de transférer l'ensemble de données associé au premier arc orienté vers la deuxième page, et si un deuxième arc orienté allant du deuxième nœud vers le premier nœud existe, de transférer vers la première page au moins une partie de l'ensemble de données associé à ce deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données, et s'il existe au moins un troisième arc orienté allant du premier ou du deuxième nœud vers un troisième nœud distinct du premier et du deuxième nœud, de répartir ledit au moins un ensemble de données associé audit au moins un troisième arc entre la première page et/ou la deuxième page ;
o un module 4A4 de mise à jour configuré pour mettre à jour la version courante G du graphe de sorte à refléter les transferts et la répartition des ensembles de données considérés par le module de détermination ; et — un module 4B de génération, configuré pour générer un ensemble d'instructions à partir des séquences de commandes ordonnées obtenues lors de chaque itération par le module de traitement 4A.
Les fonctions des différents modules du dispositif de génération 4 sont décrites plus en détail ultérieurement.
De façon similaire, dans le mode de réalisation décrit ici, l'objet connecté 2 a l'architecture matérielle d'un ordinateur telle qu'illustrée à la figure 3. Il comprend notamment un processeur 9, une mémoire morte 10, une mémoire vive 11 contenant la mémoire tampon BUF mentionnée précédemment, la mémoire persistante (i.e. non volatile) 3 dans laquelle se trouve stocké le fichier de données LOG, ainsi que des moyens de communication 12, lui permettant notamment de communiquer avec le dispositif de génération 4, et de recevoir les instructions que celui-ci a générées pour faciliter la mise à jour sur place du fichier logiciel LOG. Ils peuvent comprendre par exemple une interface de communication sans fil, telle qu'une interface Bluetooth ou WiFI ou cellulaire (ex. 3G, 4G, ou 5G).
Dans le mode de réalisation décrit ici, la mémoire tampon BUF est une mémoire de travail de taille déterministe égale à la taille d'une page (autrement dit ici 4096 octets).
La mémoire morte 10 de l'objet connecté 2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 9 et sur lequel est enregistré un programme d'ordinateur PROG2 conforme à l'invention, comportant des instructions pour l'exécution d'un procédé de mise à jour selon l'invention.
Le programme PROG2 définit divers modules fonctionnels et logiciels ici de l'objet connecté 2, aptes à mettre en œuvre les étapes du procédé de mise à jour selon l'invention et s'appuyant sur les éléments matériels 3, 9-12 de l'objet connecté 2. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré à la figure 1 :
— un module 2A d'obtention, apte à obtenir l'ensemble d'instructions INST générées par le dispositif de génération 4 et un fichier delta FA comprenant une pluralité d'instructions conduisant à la version finale Vfin du fichier de données ;
— un module 2B de génération configuré pour générer une pré-image Vmid de la version finale Vfin du fichier de données LOG en appliquant l'ensemble d'instructions INST reçu du dispositif de génération 4 à la version initiale Vinit du fichier de données ; et — un module 2C d'application, configuré pour appliquer des instructions du fichier delta FA à la pré-image Vmid générée et obtenir la version finale Vfin du fichier de données. Dans le mode de réalisation décrit ici, le fichier delta FA contient des instructions reflétant les différences entre la pré-image Vmid et la version finale Vfin du fichier de données LOG.
Les fonctions des différents modules de l'objet connecté 2 sont décrites plus en détail ultérieurement.
On note que dans un autre mode de réalisation, le fichier delta FA peut comprendre les instructions INST générées par le dispositif de génération 4. Dans un autre mode de réalisation, le fichier delta FA peut correspondre au fichier delta initial FAO et l'objet connecté 2 peut être configuré pour ne tenir compte que des instructions du fichier delta initial FAO pertinentes pour obtenir à partir de la pré-image Vmid la version finale Vfin du fichier LOG.
La figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de génération d'instructions INST selon l'invention telles qu'elles sont mises en œuvre, dans un mode particulier de réalisation, par le dispositif de génération 4.
Comme mentionné précédemment, ces instructions INST ont pour dessein de faciliter les opérations mises en œuvre par l'objet connecté 2 pour la mise à jour sur place du fichier de données LOG, lorsque cette mise à jour comprend un réseau de conflits entre les pages de données du fichier de données LOG devant être modifiées.
Conformément à l'invention, ces instructions INST sont générées par le dispositif de génération 4 au moyen d'un procédé itératif mis en œuvre via son module de traitement 4A, et s'appuyant sur une modélisation au moyen d'un graphe orienté G de la situation conflictuelle (existence d'un réseau de conflits) entre les pages du fichier de données LOG. Ce graphe orienté G est initialisé par le module 4A1 d'initialisation (étape E10) et mis à jour par le module 4A2 de mise à jour du dispositif de génération 4 à chaque itération iter pour refléter l'évolution du réseau de conflits à l'issue de chaque itération.
Le graphe orienté G est un graphe comportant une pluralité de nœuds et d'arcs orientés reliant ces nœuds. Chaque nœud du graphe G représente une page distincte de la mémoire persistante 3 de l'objet connecté 2 occupée par le fichier de données LOG. Chaque arc du graphe G allant d'un nœud de départ vers un nœud de destination est associé à un ensemble de données appartenant à la page représentée par le nœud de départ et devant être transféré vers la page représentée par le nœud d'arrivée pour obtenir la version finale du fichier de données.
Lors de l'initialisation du graphe (étape E10), les nœuds du graphe G représentent les pages de la version initiale Vinit du fichier de données LOG qui font l'objet de transferts de données entre la version initiale Vinit et la version finale Vfin du fichier de données LOG (i.e. qui sont destinées à recevoir des données d'une autre page du fichier et/ou qui sont destinées à transférer des données vers une autre page du fichier). La version du graphe G ainsi initialisée est utilisée comme version courante du graphe G à l'itération iter=l.
La figure 5 fournit un exemple de graphe G à l'itération iter=l correspondant au réseau de conflits exposé à la table 1. Il comprend quatre nœuds NI, N2, N3 et N4 correspondant respectivement aux quatre pages PI, P2, P3 et P4 situées aux adresses mémoires 0x1000, 0x2000, 0x3000 et 0x4000. Dans l'exemple de la figure 5, le graphe G pour l'itération iter=l (noté G(iter= 1)) comprend également plusieurs arcs orientés et plus spécifiquement : — trois arcs orientés partant du nœud NI représentant la page PI, à savoir :
o un arc L1 allant vers le nœud N2 représentant la page P2 et associé à l'ensemble de données B qui doit être transféré lors de la mise à jour, de la page PI vers la page P2 ;
o un arc L2 allant vers le nœud N3 représentant la page P3 et associé à l'ensemble de données C qui doit être transféré lors de la mise à jour, de la page PI vers la page P3;
o un arc L3 allant vers le nœud N4 représentant la page P4 et associé à l'ensemble de données D qui doit être transféré lors de la mise à jour, de la page PI vers la page P4 ;
— trois arcs orientés partant du nœud N2 représentant la page P2, à savoir :
o un arc L4 allant vers le nœud NI et associé à l'ensemble de données E qui doit être transféré lors de la mise à jour de la page P2 vers la page PI ;
o un arc L5 allant vers le nœud N3 et associé à l'ensemble de données G qui doit être transféré lors de la mise à jour, de la page P2 vers la page P3 ;
o un arc L6 allant vers le nœud N4 et associé à l'ensemble de données H qui doit être transféré lors de la mise à jour, de la page P2 vers la page P4 ;
— trois arcs orientés partant du nœud N3 représentant la page P3, à savoir :
o un arc L7 allant vers le nœud NI et associé à l'ensemble de données I qui doit être transféré lors de la mise à jour, de la page P3 vers la page PI ;
o un arc L8 allant vers le nœud N2 et associé à l'ensemble de données J qui doit être transféré lors de la mise à jour, de la page P3 vers la page P2 ;
o un arc L9 allant vers le nœud N4 et associé à l'ensemble de données K qui doit être transféré lors de la mise à jour, de la page P3 vers la page P4 ;
— trois arcs orientés partant du nœud N4 représentant la page P4, à savoir :
o un arc L10 allant vers le nœud NI et associé à l'ensemble de données M qui doit être transféré lors de la mise à jour, de la page P4 vers la page PI ;
o un arc LH allant vers le nœud N2 et associé à l'ensemble de données N qui doit être transféré lors de la mise à jour, de la page P4 vers la page P2 ;
o un arc L12 allant vers le nœud N3 et associé à l'ensemble de données O qui doit être transféré lors de la mise à jour, de la page P4 vers la page P3.
Chaque arc du graphe est orienté dans le sens du transfert de données qui doit être opéré entre les pages du fichier de données pour obtenir la version finale Vfin. A l'itération iter=l, les pages en question sont les pages de la version initiale Vinit du fichier. Au fil des itérations, ces pages évoluent « virtuellement » en fonction des transferts et des répartitions des ensembles de données qui ont été opérées par le dispositif de génération 4 et plus précisément par son module de traitement 4A (via son module 4A3 de détermination), de sorte que les arcs du graphe sont susceptibles d'évoluer de même que le contenu des pages représentées par les nœuds. On suppose ici que ce contenu est mentionné dans des métadonnées associées à chaque nœud du graphe. Ainsi, la mise à jour de la version courante du graphe G à chaque itération comprend une mise à jour des métadonnées associées aux nœuds du graphe (ceux qui ont été considérés durant l'itération courante) et une mise à jour de métadonnées associées aux arcs du graphe représentant les ensembles de données devant être transférés entre les nœuds de départ et les nœuds de destination de ces arcs.
Conformément à l'invention, tant que le dispositif de génération 4 détecte un arc orienté dans la version courante du graphe G (réponse oui à l'étape test E20), il met en œuvre une nouvelle itération de traitement de ce graphe (indexée par iter) (étape E30). Sinon, le procédé de génération est arrêté (étape E40).
Durant chaque itération, le dispositif de génération 4 sélectionne, via son module 4A2 de sélection, un arc orienté de la version courante du graphe allant d'un premier nœud vers un deuxième nœud (premier arc orienté au sens de l'invention) (étape E30). A titre illustratif, on suppose ici que le module 4A2 sélectionne l'arc orienté L1 allant du nœud NI (premier nœud au sens de l'invention) représentant la page PI (première page au sens de l'invention) vers le nœud N2 (deuxième nœud au sens de l'invention) représentant la page P2 (deuxième page au sens de l'invention), et associé à l'ensemble de données B.
Dans le mode de réalisation décrit ici, le module 4A2 de sélection sélectionne l'arc à traiter de façon aléatoire. En variante, d'autres heuristiques peuvent être envisagées et des critères de sélection peuvent être fixés pour sélectionner l'arc à traiter durant l'itération courante. Par exemple, le module 4A2 de sélection peut s'efforcer de sélectionner lorsqu'un tel arc existe, un arc tel que la taille de l'ensemble de données associé à cet arc soit supérieure à la somme des tailles des ensembles de données associés aux arcs orientés partant du nœud de destination de cet arc. Bien entendu d'autres critères peuvent être envisagés. Il convient de noter qu'il n'est pas toujours possible d'identifier dans le graphe un arc vérifiant un tel critère. En cas d'échec, le module 4A2 peut être configuré pour prendre en compte un autre critère ou pour sélectionner de façon aléatoire un arc.
Dans le mode de réalisation décrit ici, suite à la sélection de l'arc orienté, le module 4A3 de détermination du dispositif de génération 4 vérifie si l'arc orienté sélectionné répond à un critère CRIT1 prédéterminé (étape test E50). Dans l'exemple illustré ici, le critère CRIT1 dispose que la taille de l'ensemble de données associé à l'arc orienté sélectionné est supérieure à la somme des tailles des ensembles de données associés aux arcs orientés partant du nœud de destination de cet arc. On note que ce critère peut coïncider avec l'un des critères pris en compte pour la sélection.
La vérification ou la non vérification du critère CRfTl conditionne ici la façon dont le module 4A3 de détermination dérive pour l'itération courante, les commandes qui vont permettre de gérer le réseau de conflits présent dans le graphe.
Plus précisément, dans le mode de réalisation décrit ici, si le critère CRIT1 n'est pas vérifié par l'arc sélectionné (réponse non à l'étape test E50), le module 4A3 de détermination dérive une séquence ordonnée de commandes CMD(iter) pour l'itération courante de la façon suivante. On suppose que c'est le cas ici de l'arc orienté sélectionné L1 partant du nœud NI et allant vers le nœud N2.
Le module 4A3 de détermination détermine en premier lieu une nouvelle disposition « virtuelle » des pages PI et P2 représentées respectivement par les nœuds NI et N2 visant à supprimer l'arc orienté L1 du graphe (étape E60). Il convient de noter que l'on parle ici de disposition virtuelle des pages PI et P2 dans le sens où il s'agit d'un artifice qui permet au module 4A3 de déterminer la séquence de commandes CMD et non pas de pages réellement générées par le module 4A3 de détermination. La détermination de cette nouvelle disposition « virtuelle » des pages PI et P2 est illustrée pas à pas à la figure 6 pour mieux comprendre la démarche mise en œuvre par le module 4A3 de détermination.
Plus particulièrement pour déterminer cette nouvelle disposition virtuelle des pages PI et P2, le module 4A3 de détermination répertorie tout d'abord ici dans une liste SUP-P tous les ensembles de données contenus dans les pages PI et P2 (étape G10 sur la figure 6). Dans l'exemple envisagé à la table 1 cette liste SUP-P comprend les ensembles A-B-C-D-E-F-G-H. Pour mémoire, par souci de simplification, on suppose dans l'exemple envisagé ici que les ensembles AB-C-D sont disjoints deux à deux, de même que les ensembles E-F-G-H.
Puis il attribue (étape G20) :
— à une nouvelle version « virtuelle » VIRT-P1 de la page PI (ayant la même taille que la page PI), l'ensemble de données déjà compris le cas échéant dans PI et conservé(s) dans la page PI dans la version finale Vfin du fichier. Dans l'exemple envisagé à la table 1, l'ensemble A est attribué à la version virtuelle VIRT-P1 ; et — à une nouvelle version « virtuelle » VIRT-P2 de la page P2 (ayant la même taille que la page P2) :
o l'ensemble de données associé à l'arc orienté L1 allant du nœud NI vers le nœud N2, autrement dît, devant être transféré de la page PI vers la page P2 du fichier LOG conformément à la version finale Vfin. Dans l'exemple envisagé à la table 1, l'ensemble B est également attribué à la version virtuelle VIRT-P2 ; et o l'ensemble de données déjà compris le cas échéant dans P2 et conservé dans la page P2 dans la version finale Vfin du fichier. Dans l'exemple envisagé à la table 1, l'ensemble F est attribué à la version virtuelle VIRT-P2.
On note que les ensembles B et F peuvent être attribués à la page VIRT-P2 dans l'ordre dans lequel ils se trouvent dans la pré-image ou dans un ordre différent.
Si en outre, un arc orienté existe dans la version courante du graphe G allant du nœud N2 vers le nœud NI (deuxième arc orienté au sens de l'invention), le module 4A3 de détermination attribue à la version virtuelle VIRT-P1 de la page PI, l'ensemble de données associé à cet arc. Dans l'exemple envisagé à la table 1, un tel arc existe (il s'agit de l'arc L4) et est associé à l'ensemble de données E de sorte que l'ensemble E est attribué à la version virtuelle VIRT-P1.
Puis dans le mode de réalisation décrit ici, le module 4A3 de détermination examine s'il existe au moins un autre arc orienté allant du nœud NI ou du nœud N2 vers un autre nœud du graphe distinct des nœuds NI et N2 (troisième(s) arc(s) orienté(s) au sens de l'invention) (étape G30). Dans l'exemple envisagé à la table 1, plusieurs arcs vérifiant cette définition existent, à savoir :
— l'arc L2 partant du nœud NI, allant vers le nœud N3 et associé à l'ensemble de données C;
— l'arc 13 partant du nœud NI, allant vers le nœud N4 et associé à l'ensemble de données D;
— l'arc L5 partant du nœud N2, allant vers le nœud N3 et associé à l'ensemble de données G; et — l'arc L6 partant du nœud N2, allant vers le nœud N4 et associé à l'ensemble de donnéesH.
Le module 4A3 de détermination répartit alors les ensembles de données C, D, G, H ainsi identifiés entre les versions virtuelles VIRT-P1 et VIRT-P2 (étape G40). On note que si aucun arc orienté allant du nœud NI ou du nœud N2 vers un autre nœud n'existe dans le graphe, les configurations des versions virtuelles VIRT-P1 et VIRT-P2 sont celles obtenues à l'issue de l'étape G20.
A cet effet, le module 4A3 de détermination détermine dans un premier temps si parmi les arcs orientés identifiés lors de l'étape G30, certains vont vers le même nœud. C'est le cas ici des arcs L2 et L5 qui partent respectivement des nœuds NI et N2 et vont vers le même nœud N3, et des arcs L3 et L6 qui partent respectivement des nœuds NI et N2 et vont vers le même nœud N4.
Dans le mode de réalisation décrit ici, si de tels arcs existent dans la version courante du graphe, le module 4A3 de détermination agrège (i.e. réunit ou concatène) les ensembles de données correspondant à ces arcs allant vers le même nœud (étape G40). Autrement dit, dans l'exemple envisagé ici, il agrège les ensembles de données C et G en un (« super ») ensemble de données C+G, et les ensembles de données D et H en un (« super ») ensemble de données D + H.
Puis il classe les ensembles de données obtenus par ordre décroissant de leur taille (si aucun « super » ensemble de données n'a été généré à partir des ensembles C, D, G, H, il classe les ensembles de données C, D, G, H). On suppose par exemple ici que la taille de C+G est plus supérieure à la taille de D+H.
Le module 4A3 de détermination attribue ensuite les ensembles de données C+G et D+H ainsi classés par taille décroissante à la version virtuelle VIRT-P1 de la page PI tant que celleci contient suffisamment de place pour contenir les ensembles de données qui lui sont attribués dans leur intégralité. Autrement dit, le module 4A3 de détermination examine si la version virtuelle VIRT-P1 peut contenir l'ensemble C+G dans son intégralité. Si tel est le cas, il attribue l'ensemble de données C+G à la version virtuelle VIRT-P1 et détermine l'espace mémoire restant sur la version virtuelle VIRT-P1 suite à cette attribution.
Puis il examine si, compte tenu de l'espace mémoire restant déterminé, la version virtuelle VIRT-P1 est en mesure de contenir l'ensemble D+H dans son intégralité, etc. Si tel est le cas, il attribue l'ensemble D+H dans son intégralité à la version virtuelle VIRT-P1 et détermine l'espace mémoire restant sur la version virtuelle VIRT-P1 après cette attribution, etc., jusqu'à ce que l'espace mémoire restant sur la version virtuelle VIRT-P1 ne permette plus de contenir l'ensemble de données examiné. On suppose ici par exemple que la version virtuelle VIRT-P1 peut contenir l'ensemble de données C+G mais ne peut pas contenir l'ensemble de données D+H dans son intégralité.
Le module 4A3 de détermination examine alors si la version virtuelle VIRT-P2 peut contenir l'ensemble de données restant à attribuer D+H. Si tel est le cas, il attribue l'ensemble D+H dans son intégralité à la version virtuelle VIRT-P2. Puis il examine si d'autres ensembles de données restent à attribuer et procède de la même façon avec ces ensembles de données.
Si le module 4A3 de détermination détermine qu'un ensemble de données ne peut être attribué en intégralité à la version virtuelle VIRT-P2, alors il fragmente cet ensemble de données pour le répartir sur les versions virtuelles VIRT-P1 et VIRT-P2 compte tenu de l'espace mémoire disponible sur les versions virtuelles VIRT-P1 et VIRT-P2. Il convient de noter que les ensembles de données à répartir provenant des pages PI et P2, il existe nécessairement l'espace mémoire nécessaire pour accueillir tous ces ensembles de données. En procédant de la sorte, et en classant par ordre de taille décroissante (ou croissante) les ensembles de données à répartir, on s'assure qu'un seul ensemble de données au plus devra être fractionné pour être réparti entre les deux pages.
Par ailleurs, en agrégeant les ensembles de données destinés à un même nœud, on optimise les transferts de données à venir en diminuant le nombre d'arcs dans la version mise à jour du graphe. Toutefois cette étape est optionnelle, et le module 4A3 de détermination peut s'affranchir d'agréger les ensembles de données destinés à un même nœud et répartir individuellement les ensembles de données C, D, G et H.
On note que dans l'exemple envisagé ici, le module 4A3 de détermination a commencé l'attribution des ensembles de données par la version virtuelle VIRT-P1 de la page PI. Toutefois, il peut indifféremment commencer par la version virtuelle VIRT-P2 de la page P2. Par ailleurs, ce qui a été décrit ici pour quatre ensembles de données C, D, G et H (ou deux ensembles de données agrégés C+G et D+H) peut être appliqués bien entendu pour un nombre différent d'ensembles de données, le module 4A3 de détermination procédant de la même façon :
— en attribuant dans l'ordre décroissant de leur taille, chaque ensemble de données à répartir à l'une des pages PI et P2 (ou plus précisément ici à la version virtuelle de l'une des pages) tant que celle-ci contient suffisamment de place pour contenir les ensembles de données qui lui sont attribués dans leur intégralité ;
— en attribuant les ensembles de données restant à l'autre page tant que celle-ci contient suffisamment de place pour contenir les ensembles de données restant dans leur intégralité ; et — s'il reste un ensemble de données non attribué, en fragmentant le contenu de cet ensemble de données de façon à le répartir entre les deux pages.
A l'issue de l'étape G40, le module 4A3 de détermination obtient les versions virtuelles VIRT-P1 et VIRT-P2 suivantes des pages PI et P2:
— VIRT-P1 =A-E-C-G (ou de façon équivalente A - E - C+G, l'agrégation réalisée consistant en une simple concaténation des ensembles de données) ; et — VIRT-P2 = B - F - D - H (ou de façon équivalente B - F - D+H).
Il convient de noter que les pages PI et P2, lorsqu'elles se trouvent dans ces versions virtuelles, ne sont plus liées par un arc : autrement dit, il n'y a plus de données à transférer entre les versions virtuelles VIRT-P1 et VIRT-P2. Cette caractéristique avantageuse est illustrée plus en détail ultérieurement.
A partir de ces versions virtuelles, le module 4A3 de détermination détermine une séquence ordonnée de commandes permettant de passer des pages PI et P2 à leurs versions virtuelles VIRT-P1 et VIRT-P2 en utilisant la mémoire tampon BUF de l'objet connecté 2 (étape E70 sur la figure 4). Les versions virtuelles VIRT-P1 et VIRT-P2 constituent donc les nouvelles versions attendues des pages PI et P2 : autrement dit, dans l'exemple illustré, la séquence ordonnée de commandes doit comprendre des commandes permettant, en utilisant la mémoire tampon BUF de l'objet connecté 2 :
— de transférer l'ensemble de données B associé à l'arc orienté LI (premier arc orienté au sens de l'invention) vers la page P2, et de transférer vers la page PI l'ensemble de données E associé à l'arc orienté L4 allant de la page P2 vers la page PI ; et — de répartir les ensembles de données C, D, G, H associés aux arcs L2, L3, L5 et L6 entre les pages PI et P2.
Elles doivent également permettre d'avoir respectivement dans la page PI et dans la page P2 les ensembles de données A et F déjà contenus dans ces pages, et appartenant à la page PI et à la page P2 dans la version finale Vfin du fichier. Dans le mode de réalisation décrit ici, où la mémoire 3 de l'objet connecté est une mémoire NAND persistante est utilisée, les ensembles de données A et F doivent être réécrits sur les pages PI et P2 après l'effacement des pages PI et P2 respectivement.
Dans le mode de réalisation décrit ici, pour répondre à ces conditions, le module 4A3 de détermination génère à l'itération iter=l la séquence ordonnée CMD(iter) de commandes suivante :
— une première commande de stockage, dans la mémoire tampon BUF, du contenu de la page P2 représentée par le nœud N2 ;
— une première commande d'effacement de la page P2 (optionnelle selon la mémoire persistante considérée) ;
— une première commande d'écriture sur la page P2 dans la mémoire persistante 3 de l'objet connecté 2 :
o depuis la mémoire tampon BUF : des données contenues (ici précédemment contenues avant son effacement) dans la page P2 et présentes dans la page P2 de la version finale Vfin du fichier, autrement dit l'ensemble de données F, o depuis la page PI : de l'ensemble de données A associé à l'arc orienté LI ; et o depuis la mémoire tampon BUF et/ou depuis la page PI : de l'ensemble de données agrégé D+H réparti sur la page P2 lors de l'étape G40 ;
On note que cette commande permet d'obtenir une page P2 dans la configuration donnée par sa version virtuelle VIRT-P2 (c'est-à-dire contenant les ensembles de données B-F-D+H) ;
— une deuxième commande de stockage, dans la mémoire tampon BUF, des ensembles de données contenus dans la page PI représentée par le nœud NI à l'exception des ensembles de données déjà écrits via la première commande d'écriture sur la page P2 : il s'agit ici d'écrire dans la mémoire tampon BUF, les ensembles de données A et C tout en préservant les ensembles de données E et G qui n'ont pas encore été copiés vers la page PI. On note que la mémoire tampon BUF qui a une taille d'une page contient la place pour stocker ces quatre ensembles de données puisque le module 4A3 de détermination les a attribués à la page PI ;
— une deuxième commande d'effacement de la page PI (optionnelle selon la mémoire persistante considérée) ; et — une deuxième commande d'écriture, sur la page PI, depuis la mémoire tampon BUF, des ensembles de données contenues dans la page P2 (i.e. ici précédemment contenues avant son effacement) et présentes dans la page P2 de la version finale Vfin du fichier, autrement dit l'ensemble de données A, de l'ensemble de données E associé à l'arc orienté L4 allant du nœud N2 vers le nœud NI, et de l'ensemble de données agrégés C+G réparti lors de l'étape G40 sur la page PI.
Il convient de noter que l'ordre de ces commandes a son importance pour éviter de perdre des données lors des transferts opérés.
Dans le mode de réalisation décrit ici, on a considéré la notion de versions virtuelles des pages PI et P2 pour déterminer une nouvelle configuration de ces pages permettant de traiter l'arc orienté sélectionné et de ne plus avoir à transférer de données entre les pages PI et P2 dans cette nouvelle configuration. D'autres approches peuvent bien entendu être utilisées pour le module 4A3 de détermination pour déterminer une configuration des pages PI et P2 permettant d'obtenir le même résultat, c'est-à-dire, lorsqu'un premier arc orienté allant d'un premier nœud NI représentant une première page PI vers un deuxième nœud N2 représentant une deuxième page P2 est sélectionné, une séquence ordonnée de commandes permettant, sans perdre de données, et en utilisant la mémoire tampon BUF de l'objet connecté 2 :
— d'avoir dans la première page PI et dans la deuxième page P2 les ensembles de données déjà contenus dans ces pages et appartenant à la première page PI et à la deuxième page P2 de la version finale du fichier. On note que si l'ensemble de données associé au premier arc coïncide en tout ou partie avec un ensemble de données contenu dans la première page PI et appartenant à la première page PI de la version finale Vfin du fichier, on ne conserve ou ne copie dans la première page PI que la partie des données de cet ensemble de données qui ne coïncide pas avec l'ensemble de données associé au premier arc (pour des raisons de place disponible dans la première page Pl). Il sera toujours possible à un stade ultérieur de récupérer dans la première page PI les données manquantes pour la version finale du fichier, celles-ci étant disponibles dans la page P2 de la version finale du fichier. Dans l'exemple illustratif envisagé ici, les ensembles A et B étant disjoints, on a dans la première page PI l'ensemble A dans son intégralité compris dans la page PI de la version finale ;
— de transférer l'ensemble de données associé au premier arc orienté sélectionné vers la deuxième page P2, et si un deuxième arc orienté allant du deuxième nœud N2 vers le premier nœud NI existe, de transférer vers la première page PI, au moins une partie de l'ensemble de données associé à ce deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données. Il sera toujours possible à un stade ultérieur de récupérer dans la première page PI les données manquantes pour la version finale du fichier, celles-ci étant disponibles dans la page P2 de la version finale du fichier. S'il n'y a pas coïncidence entre les ensembles de données, tout l'ensemble de données associé au deuxième arc est transféré vers la page PI. C'est le cas notamment dans l'exemple illustratif envisagé ici où les ensembles E et F sont disjoints : on transfère alors vers la première page PI l'ensemble E dans son intégralité, et — s'il existe au moins un troisième arc orienté allant du premier ou du deuxième nœud vers un troisième nœud distinct du premier et du deuxième nœud, de répartir ledit au moins un ensemble de données associé audit au moins un troisième arc entre la première page PI et/ou la deuxième page P2, dans la limite de la place disponible sur ces pages.
Suite à la détermination des commandes CMD(iter), le module 4A4 de mise à jour du dispositif de génération met à jour la version courante du graphe G(iter) pour tenir compte des transferts et des répartitions de données qui résultent des commandes CMD (étape E80). Autrement dit, il met à jour le graphe G(iter) pour refléter la nouvelle disposition des pages PI et P2 représentée par les versions virtuelles VIRT-P1 et VIRT-P2. Cette mise à jour, comme mentionné précédemment, consiste ici à mettre à jour les métadonnées associées aux nœuds du graphe G (ceux qui ont été considérés durant l'itération iter, à savoir ici les nœuds NI et N2) et les métadonnées associées aux arcs du graphe compte tenu des nouvelles dispositions de données dans les pages représentées par les nœuds. La version courante de G(iter) ainsi mise à jour est utilisée comme version courante du graphe à l'itération suivante (i.e. G(iter+1)).
La figure 7A illustre le graphe G mis à jour lors de l'étape E80.
Les métadonnées associées au nœud NI contiennent maintenant les ensembles de données A-E-C-G, tandis que les métadonnées associées au nœud N2 contiennent les ensembles B-F-D-H. Les métadonnées associées aux autres nœuds du graphe (N3 et N4) sont restées inchangées.
Les arcs Ll, L4, L3 et L5 n'existent plus, tandis que les arcs L2 et L6 sont maintenant associés aux ensembles de données C+G (ou de façon équivalente C-G) et D+H (ou de façon équivalente D-H) respectivement.
On note que si seulement un transfert partiel de l'ensemble de données E a été opérée vers la page PI (dans le cas où les ensembles E et F ne sont pas disjoints), l'arc L4 est maintenu et associé à la partie manquante de l'ensemble de données E qui n'a pas été encore transférée vers la page Pl. De même, si l'ensemble A n'a pas été maintenu en entier dans la page PI car il comportait une partie en commun avec l'ensemble de données B, l'arc L4 est conservé et la partie de l'ensemble A non maintenue dans la page PI (mais présente dans l'ensemble de données B transféré vers la page P2) est associée à cet arc L4.
Comme mentionné précédemment, dans le mode de réalisation décrit ici, si l'arc orienté sélectionné lors de l'étape E30 (L1 dans l'exemple envisagé) vérifie le critère CR1T1 (pour mémoire, la taille de l'ensemble de données associé à l'arc orienté sélectionné est supérieure à la somme des tailles des ensembles de données associés aux arcs orientés partant du nœud de destination de cet arc), le module 4A3 de détermination procède différemment des étapes E60, E70 et E80 décrites précédemment pour déterminer une séquence de commandes CMD', en vue notamment d'optimiser la séquence de commandes déterminée et les traitements à effectuer (notamment par les modules de détermination et de mise à jour).
Plus précisément, si le critère CRUl est vérifié par l'arc sélectionné (réponse oui à l'étape test E50), le module 4A3 de détermination détermine une séquence de commandes CMD' qui permet au moyen de la mémoire tampon d'obtenir une nouvelle configuration des pages PI et P2 telle que le nœud N2 représentant la page P2 est exclu du réseau de conflit (étape E90). A cet effet, le module 4A3 de détermination exploite le fait que la taille de l'ensemble de données associé à l'arc orienté sélectionné (L1 ici, l'ensemble de données en question étant l'ensemble A) est supérieure à la somme des tailles des ensembles de données associés aux arcs orientés partant du nœud N2 (i.e. les arcs L4, L5 et L6 ici associés respectivement aux ensembles de données E, G et H).
Plus spécifiquement, compte tenu de cette propriété, le module 4A3 de détermination peut déterminer une séquence de commandes CMD' (potentiellement différente de celle qu'il aurait généré en appliquant les étapes E60 et E70) qui permet, au moyen de la mémoire tampon BUF de l'objet connecté 2 de taille égale à une page :
— de transférer vers la deuxième page P2, chaque ensemble de données associé à un arc orienté de la version courante du graphe arrivant sur le nœud N2, autrement dit dans l'exemple envisagé des ensembles de données B, J et N associés respectivement aux arcs orientés LI, L8 et LU ; et — de transférer vers la première page PI de chaque ensemble de données associé à un arc orienté de la version courante du graphe partant du nœud N2, autrement dit dans l'exemple envisagé des ensembles E, H et G associés respectivement aux arcs L4, L5 et L6 partant du nœud N2, puis que leur taille est inférieure à l'ensemble de données B précédemment transféré depuis la page PI vers la page P2.
Dans le mode de réalisation décrit ici, pour répondre à ces conditions, le module 4A3 de détermination génère à l'itération iter=l, la séquence ordonnée CMD'(iter) de commandes suivante :
— une première commande de stockage, dans la mémoire tampon BUF, du contenu de la page P2 représentée par le nœud N2, c'est-à-dire dans l'exemple envisagé, des ensembles de données E, F, G, H ;
— une première commande d'effacement de la page P2 (optionnelle selon la mémoire persistante considérée) ;
— une première commande d'écriture sur la page P2 dans la mémoire persistante 3 de l'objet connecté 2 :
o depuis la mémoire tampon BUF : des données contenues (ici précédemment contenues avant son effacement) dans la page P2 et présentes dans la page P2 de la version finale Vfin du fichier, autrement dit l'ensemble de données F, o depuis les pages Pl, P3 et P4 : des ensembles de données B, J et N associés respectivement aux arcs orientés LI, L8 et LU arrivant sur le nœud N2 ;
On note que cette commande permet d'obtenir une page P2 dans la configuration correspondant à la page P2 de la pré-image Vmid, autrement dit de la version finale (c'est-àdire contenant les ensembles de données B-F-J-N, indépendamment de l'ordre à proprement parler des données de ces ensembles) ;
— une deuxième commande de stockage, dans la mémoire tampon BUF, des ensembles de données contenus dans la page PI représentée par le nœud NI à l'exception des ensembles de données déjà écrits via la première commande d'écriture sur la page P2 : il s'agit ici d'écrire dans la mémoire tampon BUF, les ensembles de données A, C et D (B ayant déjà été copié sur la page P2) tout en préservant l'ensemble E provenant de la page P2 qui n'a pas encore été copié vers la page PI. Les ensembles de données A, C et D viennent s'ajouter dans la mémoire tampon aux ensembles de données E,G et H précédemment copiés via la première commande de stockage depuis la page P2. On note que la mémoire tampon BUF qui a une taille d'une page contient la place pour stocker ces six ensembles de données puisque la taille de B est supérieure à la taille de E, G et H réunis ;
— une deuxième commande d'effacement de la page PI (optionnelle selon la mémoire persistante considérée) ; et — une deuxième commande d'écriture sur la page PI dans la mémoire persistante 3 de l'objet connecté 2, depuis la mémoire tampon BUF, des ensembles de données A, C, D, E, G et H.
Ces commandes conduisent les pages PI et P2 dans une nouvelle configuration à savoir la page PI contient les ensembles de données A, C, D, E, G, H tandis que la page P2 contient les ensembles de données B, F, J et N. La page P2 contient ainsi les ensembles de données qu'elle doit contenir dans la version finale Vfin du fichier. Elle est donc en quelque sorte sortie du réseau de conflits à gérer.
Suite à la détermination des commandes CMD'(iter), le module 4A4 de mise à jour du dispositif de génération met à jour la version courante du graphe G(iter) pour tenir compte des transferts et des répartitions de données qui résultent des commandes CMD' (étape E100).
Autrement dit, il met à jour le graphe G(iter) pour refléter la nouvelle disposition des pages PI et P2. Cette mise à jour, comme mentionné précédemment pour l'étape E80, consiste ici à mettre à jour les métadonnées associées aux nœuds du graphe G (ceux qui ont été considérés durant l'itération iter, à savoir ici les nœuds NI et N2) et les métadonnées associées aux arcs du graphe compte tenu des nouvelles dispositions de données dans les pages représentées par les nœuds. La version courante de G(iter) ainsi mise à jour est utilisée comme version courante du graphe à l'itération suivante (i.e. G(iter+1)).
La figure 7B illustre le graphe G mis à jour lors de l'étape E100.
Les métadonnées associées au nœud NI contiennent maintenant les ensembles de données A-C-D-E-G-H, tandis que les métadonnées associées au nœud N2 contiennent les ensembles B-F-J-N. Les métadonnées associées aux autres nœuds du graphe (N3 et N4) sont restées inchangées.
Les arcs Ll, L4, L5 et L8 n'existent plus, tandis que les arcs L2 et L3 sont maintenant associés aux ensembles de données C+G (ou de façon équivalente C-G) et D+H (ou de façon équivalente D-H) respectivement.
On note que d'autres critères peuvent être examinés pour tenter de simplifier les traitements mis en œuvre par le dispositif de génération 4 pour déterminer la séquence de commandes et/ou pour simplifier cette séquence de commandes ou le jeu d'instructions généré à partir de cette séquence.
Par exemple, le module 4A3 de détermination peut examiner si l'arc sélectionné est tel que le nœud de départ de l'arc et son nœud destination sont liés par un unique arc ou par un arc bidirectionnel (autrement dit par deux arcs allant respectivement du nœud de départ vers le nœud de destination et inversement), et qu'aucun autre arc ne part de ces nœuds (nœuds isolés dans le graphe). Dans ce cas, le module 4A3 de détermination peut déterminer une séquence ordonnée de commandes permettant un simple échange des données entre les deux nœuds. A titre illustratif, si on suppose par exemple que les nœuds NI et N2 sont liés par un arc orienté Ll' allant de NI vers N2 associé à un ensemble de données A' et par un arc orienté L2' allant de N2 vers NI associé à un ensemble de données B', une séquence de commandes CMD(iter) permettant d'échanger les données entre les pages PI et P2 représentées respectivement par les nœuds NI et N2 est :
— une première commande de stockage, dans la mémoire tampon BUF de l'objet connecté 2, des données contenues dans la page P2 ;
— une première commande d'effacement du contenu de la page P2 dans la mémoire persistante 3 (peut être optionnelle) ;
— une première commande d'écriture, sur la page P2, des données destinées à être contenues dans la version finale de cette page P2 (incluant par exemple ici l'ensemble de données se trouvant sur la page PI ;
— une deuxième commande de stockage, dans la mémoire tampon BUF de l'objet connecté 2, des données de ia version finale de la page PI (incluant l'ensemble de données B' précédemment contenues dans la page P2 copiée dans la mémoire tampon BUF via la première commande de stockage) ;
— une deuxième commande d'effacement du contenu de la page PI dans la mémoire persistante 3 (peut être optionnelle) ;
— une deuxième commande d'écriture, sur la page PI, des données stockées dans la mémoire tampon BUF.
Selon un autre exemple, le module 4A3 de détermination peut examiner si l'arc sélectionné est tel que la page représentée par le nœud de départ de l'arc a suffisamment d'espace mémoire inutilisé dans sa forme finale pour stocker tout ou partie des ensembles de données contenus dans la page représentée par le nœud de destination de l'arc et destinés à être transférés vers d'autres pages dans la version finale Vfin du fichier. Selon cet exemple, le module 4A3 de détermination peut déterminer une séquence ordonnée de commandes exploitant l'espace mémoire inutilisé sur le nœud de départ dans sa forme finale.
Bien d'autres critères peuvent être envisagés et testés et conduire au remplacement des étapes E60 à E80 par des étapes plus simples. Toutefois, il convient de noter que pour un réseau de conflits quelconque, il n'est pas toujours possible de sélectionner des arcs vérifiant de tels critères. Les étapes E60 à E80 sont quant à elles toujours applicables, quelles que soient les propriétés de l'arc sélectionné lors de l'étape E30. Par conséquent, on peut envisager dans un mode de réalisation de toujours mettre en œuvre ces étapes E60 à E80 sans envisager de les optimiser. En variante, on peut envisager, comme dans le mode de réalisation décrit ici, de mettre en œuvre des étapes alternatives lorsque les arcs sélectionnés lors de l'étape E30 le permettent. Autrement dit, le procédé de génération contient dans ce cas des itérations de traitement mettant en œuvre les étape E60 à E80 et des itérations de traitement mettant en œuvre d'autres étapes de détermination et de mise à jour en remplacement des étapes E60 à E80 (comme par exemple les étapes E90 et E100) quand certains critères d'optimisation prédéterminés (tel que le critère CRIT1) sont vérifiés par les arcs sélectionnés lors de ces itérations.
A l'issue des étapes de mise à jour E80/E100, l'index de l'itération courante iter est incrémenté (étape E110) et le dispositif de génération 4 examine si la version courante du graphe G correspondant à cet index contient encore un arc orienté à traiter (étape E20).
Si tel est le cas (réponse oui à l'étape E20), une nouvelle itération de traitement du graphe est mise en œuvre et les étapes E30 à E100 sont réitérées sur la version courante du graphe G mise à jour. Les étapes E20 à E100 sont répétées tant que la version courante du graphe G mise à jour contient un arc orienté.
Sinon (réponse non à l'étape E20), le dispositif de génération 4, via son module 4B de génération, génère un jeu d'instructions INST à partir des séquences de commandes ordonnées (CMD, CMD' ou CMD) obtenues lors des différentes itérations réalisées par le module de traitement 4A (étape E40). On note que l'ensemble des séquences de commandes ordonnées obtenues permettent de transformer la version initiale du fichier LOG en la pré-image Vmid.
Autrement dit, lors de cette étape, il traduit (code) les différentes séquences de commandes ordonnées en un ensemble ordonné d'instructions compréhensibles par l'objet connecté 2 et destinées à être appliquées par celui-ci pour gérer le conflit cyclique. Ces instructions peuvent comprendre notamment :
— des instructions de copie de données d'une page de la mémoire persistante vers la mémoire tampon ;
— des instructions de copie de données de la mémoire tampon vers une page de la mémoire persistante ;
— des instructions de copie de données de la mémoire tampon vers la mémoire tampon ;
— des instructions d'effacement de données de la mémoire persistante ;
— des instructions de désignation d'une page de la mémoire persistante ;
— des instructions de copie chaînée de données de la mémoire persistante vers la mémoire persistante ou la mémoire tampon ;
— des instructions de copie chaînée de données de la mémoire tampon vers la mémoire persistante ou la mémoire tampon ; etc.
Bien entendu, ces types d'instructions ne sont donnés qu'à titre illustratif et peuvent être complétés.
Parmi les instructions mentionnées ci-avant, l'instruction de désignation d'une page de la mémoire persistante peut être utilisée avantageusement pour signaler au dispositif que les instructions suivant cette instruction de désignation vont porter sur une même page (celle désignée par l'instruction de désignation) et s'affranchir dans lesdites instructions suivantes de coder la page en question. Il est ainsi possible de gagner quelques bits dans le codage des instructions.
De façon similaire, les instructions de copie étant coûteuses à coder (il est nécessaire notamment de coder les adresses de départ et de destination, ainsi que la longueur de la copie), les instructions de copie chaînée permettent de s'affranchir du codage de l'adresse de destination lorsque les données à copier sont à copier à la suite les unes des autres.
On note que chaque commande peut être codée par le module 4B de génération en une ou plusieurs instructions en fonction de différents critères (complexité de la commande, langage utilisé par l'objet connecté, optimisation des instructions, etc.). Le module 4B de génération peut également utiliser des instructions combinées ou spécialisées permettant de réduire le nombre d'instructions à transmettre à l'objet connecté 2 dans le jeu d'instructions INST (ex. instructions de copie chaînée évoquées ci-dessus, etc.). Certaines informations contenues dans les instructions peuvent également être codées de façon optimisée, etc., pour réduire l'espace alloué à l'encodage de ces informations.
Par ailleurs lors de l'étape E40, le module 4B de génération peut procéder à diverses optimisations et regrouper le cas échéant certaines commandes qui peuvent être redondantes entre deux itérations.
Dans un autre mode de réalisation de l'invention, le dispositif de génération 4 complète le jeu d'instructions INST reflétant les différentes commandes obtenues à chaque itération par d'autres instructions dans un but informatif notamment, liées à la maintenance de la mémoire tampon BUF de l'objet connecté 2 et à l'effacement des pages de mémoire, telles que par exemple une instruction ERASE signalant à l'objet connecté 2 que les données présentes sur une page ne sont plus requises et que par conséquent l'objet n'a pas à déterminer si l'adresse en cours d'écriture correspond à de la mémoire déjà effacée ou non.
Comme mentionné précédemment, le jeu d'instructions INST généré par le dispositif de génération 4 est destiné à être fourni avec un fichier delta à l'objet connecté 2 pour faciliter la mise à jour sur place du fichier de données LOG. Dans le mode de réalisation décrit ici, le fichier delta FA destiné à être fourni avec les instructions INST à l'objet connecté 2 est généré par le dispositif de génération 4 à partir du fichier delta initial FAO contenant les instructions reflétant les changements devant être opérés entre la version initiale Vinit du fichier de données LOG et sa version finale Vfin. Il contient les instructions reflétant les changements devant être opérés entre la pré-image Vmid du fichier de données LOG et sa version finale Vfin. La génération d'un tel fichier delta est connue en soi et n'est pas décrite davantage ici.
Nous allons maintenant décrire en référence à la figure 8 les principales étapes d'un procédé de mise à jour selon l'invention, dans un mode particulier de réalisation dans lequel il est mis en œuvre par l'objet connecté 2 en utilisant le jeu d'instructions INST.
On suppose que l'objet connecté 2 reçoit, via son module d'obtention 2A, le fichier delta FA ainsi que le jeu d'instructions INST générés par le dispositif de génération 4 (étape F10). Par exemple, le dispositif de génération 4 transmet ces deux éléments à l'objet connecté 2 via son interface de communication.
L'objet connecté 2 génère une pré-image Vmid du fichier LOG en appliquant, via son module 2B de génération, le jeu d'instructions INST reçu sur la version initiale Vinit du fichier de données LOG stocké dans sa mémoire persistante 3 (étape F20). Il utilise lors de l'application de ce jeu d'instructions sa mémoire tampon BUF. La génération de la pré-image est réalisée « sur place », c'est-à-dire en lieu et place dans la mémoire persistante 3 de la version initiale Vinit. Cette pré-image de la version finale du fichier de données LOG est exempte de réseau de conflits complexe à gérer.
L'objet connecté 2 applique ensuite, via son module 2C d'application, le fichier delta FA à la pré-image Vmid ainsi obtenue pour obtenir ce fichier dans sa version finale Vfin (étape F30) et terminer la mise à jour sur place du fichier LOG (étape F40).

Claims (15)

  1. REVENDICATIONS
    1. Procédé de génération d'un ensemble d'instructions (INST) destinées à un dispositif (2) pour mettre à jour sur place une version initiale d'un fichier de données en une version finale, ce fichier étant stocké sous la forme d'une pluralité de pages d'une taille prédéterminée dans une mémoire persistante du dispositif, le procédé de génération comprenant :
    — une étape d'initialisation (E10) à partir de la version initiale du fichier d'une version courante d'un graphe comprenant une pluralité de nœuds et d'arcs orientés et dans lequel chaque nœud représente une page distincte de la mémoire persistante occupée par le fichier, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à un ensemble de données contenu dans la page représentée par le nœud de départ devant être transféré vers la page représentée par le nœud de destination pour obtenir la version finale du fichier ;
    — tant que la version courante du graphe comprend au moins un arc orienté, une itération de traitement comprenant :
    o une étape de sélection (E30) dans la version courante du graphe d'un premier arc orienté allant d'un premier nœud représentant une première page vers un deuxième nœud représentant une deuxième page ;
    o une étape de détermination (E70) d'une séquence ordonnée de commandes qui permet, au moyen d'une mémoire tampon :
    de transférer l'ensemble de données associé au premier arc orienté vers la deuxième page, et si un deuxième arc orienté allant du deuxième nœud vers le premier nœud existe, de transférer vers la première page, au moins une partie de l'ensemble de données associé à ce deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données, et s'il existe au moins un troisième arc orienté allant du premier ou du deuxième nœud vers un troisième nœud distinct du premier et du deuxième nœud, de répartir ledit au moins un ensemble de données associé audit au moins un troisième arc entre la première page et/ou la deuxième page ;
    o une étape de mise à jour (E80) de la version courante du graphe de sorte à refléter les transferts et la répartition des ensembles de données considérés lors de l'étape de détermination ;
    — une étape de génération (E40) dudit ensemble d'instructions à partir des séquences ordonnées de commandes déterminées lors des itérations de traitement.
  2. 2. Procédé de génération selon la revendication 1 dans lequel la mémoire tampon (BUF) a la taille prédéterminée d'une page.
  3. 3. Procédé de génération selon la revendication 1 ou 2 dans lequel ladite séquence ordonnée de commandes comprend :
    — une première commande de stockage, dans la mémoire tampon du dispositif, du contenu de la deuxième page représenté par le deuxième nœud ;
    — une première commande d'écriture sur la deuxième page, depuis la mémoire tampon et la première page, des données contenues dans la deuxième page représentée par le deuxième nœud et présentes dans la deuxième page de la version finale du fichier, de l'ensemble de données associé au premier arc orienté et des ensembles de données associés audit au moins un troisième arc répartis sur la deuxième page;
    — une deuxième commande de stockage, dans la mémoire tampon, des ensembles de données contenus dans la première page représentée par le premier nœud à l'exception des ensembles de données écrits via la première commande d'écriture sur la deuxième page et en conservant dans la mémoire tampon les ensembles de données stockés via la première commande de stockage devant être transférés vers la première page ; et — une deuxième commande d'écriture, sur la première page, depuis la mémoire tampon, des données contenues dans la première page représentée par le premier nœud et présentes dans la première page de la version finale du fichier, d'au moins une partie de l'ensemble de données associé au deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données et des ensembles de données associés audit au moins un troisième arc répartis sur la première page.
  4. 4. Procédé de génération selon l'une quelconque des revendications 1 à 3 comprenant lors de l'étape de détermination, pour répartir ledit au moins un ensemble de données associé audit au moins un troisième arc :
    — une étape d'attribution dans l'ordre décroissant de leur taille, chaque ensemble dudit au moins un ensemble de données à l'une des pages parmi la première et la deuxième page tant que celle-ci contient suffisamment de place pour contenir lesdits ensembles de données qui lui sont attribués dans leur intégralité ;
    — une étape d'attribution des ensembles de données restant à l'autre page parmi la première et la deuxième page tant que celle-ci contient suffisamment de place pour contenir lesdits ensembles de données restant dans leur intégralité ; et — s'il reste un ensemble de données non attribué, une étape de répartition du contenu de cet ensemble de données entre la première page et la deuxième page.
  5. 5. Procédé de génération selon l'une quelconque des revendications 1 à 4 comprenant lors de l'étape de détermination, pour répartir ledit au moins un ensemble de données associé audit au moins un troisième arc, s'il existe dans le graphe deux arcs orienté allant respectivement du premier et du deuxième nœud vers un même troisième nœud, une étape d'agrégation au sein d'un même ensemble de données des ensembles de données associés auxdits arcs, avant de répartir ledit ensemble de données agrégés entre la première page et/ou la deuxième page.
  6. 6. Procédé de génération selon l'une quelconque des revendications 1 à 5 dans lequel le premier arc orienté est sélectionné de façon aléatoire.
  7. 7. Procédé de génération selon l'une quelconque des revendications 1 à 6 dans lequel, si une taille de l'ensemble de données associé au premier arc orienté est supérieure à une somme des tailles des ensembles de données associés aux arcs orientés partant du deuxième nœud, ladite itération de traitement comprend, en remplacement des étapes de détermination et de mise à jour :
    — une étape de détermination (E90) d'une séquence ordonnée de commandes qui permet, au moyen de ladite mémoire tampon :
    o de transférer vers la deuxième page de chaque ensemble de données associé à un arc orienté de la version courante du graphe arrivant sur le deuxième nœud ; et o de transférer vers la première page de chaque ensemble de données associé à un arc orienté de la version courante du graphe partant du deuxième nœud ;
    — une étape de mise à jour (E100) de la version courante du graphe de sorte à refléter les transferts considérés lors de l'étape de détermination.
  8. 8. Procédé de génération selon la revendication 7 dans lequel ladite séquence ordonnée de commandes comprend :
    — une première commande de stockage, dans la mémoire tampon du dispositif, du contenu de la deuxième page représentée par le deuxième nœud ;
    — une première commande d'écriture sur la deuxième page, depuis la mémoire tampon et les pages représentées par les nœuds de départ des arcs orientés arrivant sur le deuxième nœud, des ensembles de données associés à ces arcs et des données contenues dans la deuxième page représentée par le deuxième nœud et présentes dans la deuxième page de la version finale du fichier ;
    — une deuxième commande de stockage, dans la mémoire tampon, des ensembles de données contenus dans la première page représentée par le premier nœud à l'exception de l'ensemble de données associé au premier arc orienté ;
    — une deuxième commande d'écriture sur la première page, depuis la mémoire tampon, des données contenues dans la première page représentée par le premier nœud et présentes dans la première page de la version finale du fichier, de l'ensemble de données associé au deuxième arc orienté et des ensembles de données associés aux arcs orientés partant du deuxième noeud.
  9. 9. Procédé de génération selon l'une quelconque des revendications 1 à 8 dans lequel ledit ensemble d'instructions comprend au moins une instruction parmi :
    — une instruction de copie de données d'une page de la mémoire persistante vers la mémoire tampon ;
    — une instruction de copie de données de la mémoire tampon vers une page de la mémoire persistante ;
    — une instruction de copie de données de la mémoire tampon vers la mémoire tampon ;
    — une instruction d'effacement de données de la mémoire persistante ;
    — une instruction de désignation d'une page de la mémoire persistante ;
    — une instruction de copie chaînée de données de la mémoire persistante vers la mémoire persistante ou vers la mémoire tampon ;
    — une instruction de copie chaînée de données de la mémoire tampon vers la mémoire persistante ou vers la mémoire tampon.
  10. 10. Procédé de mise à jour sur place par un dispositif (2) d'une version initiale d'un fichier de données en une version finale, ce fichier étant stocké sous la forme d'une pluralité de pages d'une taille prédéterminée dans une mémoire persistante du dispositif, ledit procédé de mise à jour comprenant :
    — une étape d'obtention (F10) d'un ensemble d'instructions (INST) générées en utilisant un procédé de génération selon l'une quelconque des revendications 1 à 8 et d'un fichier delta comprenant une pluralité d'instructions conduisant à la version finale du fichier de données ;
    — une étape de génération (F20) dans la mémoire persistante en remplacement de la version initiale du fichier, d'une pré-image de la version finale du fichier de données en appliquant ledit ensemble d'instructions à la version initiale du fichier de données ; et — une étape d'application (F30) d'instructions du fichier delta à la pré-image générée pour obtenir dans la mémoire persistante en remplacement de la pré-image, la version finale du fichier.
  11. 11. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de génération selon l'une quelconque des revendications 1 à 9 ou d'un procédé de mise à jour selon la revendication 10 lorsque ledit programme est exécuté par un ordinateur.
  12. 12. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon la revendication 11.
  13. 13. Dispositif de génération (4) d'un ensemble d'instructions destinées à un autre dispositif pour mettre à jour sur place une version initiale d'un fichier de données en une version finale, ce fichier étant stocké sous la forme d'une pluralité de pages d'une taille prédéterminée dans une mémoire persistante dudit autre dispositif, le dispositif de génération comprenant :
    — un module d'initialisation (4A1), configuré pour initialiser à partir de la version initiale du fichier, une version courante d'un graphe comprenant une pluralité de nœuds et d'arcs orientés et dans lequel chaque nœud représente une page distincte de la mémoire persistante occupée par le fichier, et chaque arc orienté allant d'un nœud de départ vers un nœud de destination du graphe est associé à un ensemble de données contenu dans la page représentée par le nœud de départ devant être transféré vers la page représentée par le nœud de destination pour obtenir la version finale du fichier ;
    — un module de traitement itératif (4A), activé tant que la version courante du graphe comprend au moins un arc orienté, ledit module comprenant un module de sélection, un module de détermination et un module de mise à jour activés lors de chaque itération de traitement tels que :
    o le module de sélection (4A2) est configuré pour sélectionner dans la version courante du graphe un premier arc orienté allant d'un premier nœud représentant une première page vers un deuxième nœud représentant une deuxième page ;
    o le module de détermination (4A3) est configuré pour déterminer une séquence ordonnée de commandes qui permet, au moyen d'une mémoire tampon :
    de transférer l'ensemble de données associé au premier arc orienté vers la deuxième page, et si un deuxième arc orienté allant du deuxième nœud vers le premier nœud existe, de transférer vers la première page, au moins une partie de l'ensemble de données associé à ce deuxième arc orienté ne coïncidant pas avec des données présentes dans la deuxième page de la version finale du fichier de données, et s'il existe au moins un troisième arc orienté allant du premier ou du deuxième nœud vers un troisième nœud distinct du premier et du deuxième nœud, de répartir ledit au moins un ensemble de données associé audit au moins un troisième arc entre la première page et/ou la deuxième page ;
    o le module de mise à jour (4A4) est configuré pour mettre à jour la version courante du graphe de sorte à refléter les transferts et la répartition des ensembles de données considérés par le module de détermination ;
    — un module de génération (4B), configuré pour générer ledit ensemble d'instructions à partir des séquences ordonnées de commandes déterminées lors des itérations de traitement.
  14. 14. Dispositif de mise à jour (2) comprenant une mémoire persistante (3) dans laquelle est stockée une version initiale d'un fichier de données sous la forme d'une pluralité de pages d'une taille prédéterminée, ledit dispositif de mise à jour comprenant :
    — un module d'obtention (2A), apte à obtenir un ensemble d'instructions générées par un dispositif de génération selon la revendication 13 et un fichier delta comprenant une pluralité d'instructions conduisant à la version finale du fichier de données ;
    — un module de génération (2B) configuré pour générer dans la mémoire persistante, en 5 remplacement de la version initiale du fichier, une pré-image de la version finale du fichier de données en appliquant ledit ensemble d'instructions à la version initiale du fichier de données ; et — un module d'application (2C), configuré pour appliquer des instructions du fichier delta à la pré-image générée et obtenir dans la mémoire persistante en remplacement de la pré-image,
    10 la version finale du fichier de données.
  15. 15. Système (1) comprenant :
    — un dispositif de mise à jour (2) selon la revendication 14, stockant dans une mémoire persistante un fichier de données dans une version initiale sous la forme d'une pluralité de
    15 pages d'une taille prédéterminée ; et — un dispositif de génération (4) selon la revendication 13, configuré pour générer un ensemble d'instructions destinées au dispositif de mise à jour pour mettre à jour sur place la version initiale du fichier de données en une version finale.
FR1856927A 2018-07-25 2018-07-25 Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees Active FR3084496B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1856927A FR3084496B1 (fr) 2018-07-25 2018-07-25 Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1856927 2018-07-25
FR1856927A FR3084496B1 (fr) 2018-07-25 2018-07-25 Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees

Publications (2)

Publication Number Publication Date
FR3084496A1 true FR3084496A1 (fr) 2020-01-31
FR3084496B1 FR3084496B1 (fr) 2020-08-07

Family

ID=63491791

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1856927A Active FR3084496B1 (fr) 2018-07-25 2018-07-25 Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees

Country Status (1)

Country Link
FR (1) FR3084496B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111453195A (zh) * 2020-04-02 2020-07-28 荣成泰祥食品股份有限公司 一种食品配送箱及减震件

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070083571A1 (en) * 2005-10-06 2007-04-12 Red Ben Ltd. Methods and systems for updating content including a compressed version
EP1956482A1 (fr) * 2007-02-09 2008-08-13 Telefonaktiebolaget LM Ericsson Génération de mises à jour delta pour dispositif de traitement
US20160124739A1 (en) * 2014-10-30 2016-05-05 Google Inc. Minimizing Image Copying During Partition Updates

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070083571A1 (en) * 2005-10-06 2007-04-12 Red Ben Ltd. Methods and systems for updating content including a compressed version
EP1956482A1 (fr) * 2007-02-09 2008-08-13 Telefonaktiebolaget LM Ericsson Génération de mises à jour delta pour dispositif de traitement
US20160124739A1 (en) * 2014-10-30 2016-05-05 Google Inc. Minimizing Image Copying During Partition Updates

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111453195A (zh) * 2020-04-02 2020-07-28 荣成泰祥食品股份有限公司 一种食品配送箱及减震件

Also Published As

Publication number Publication date
FR3084496B1 (fr) 2020-08-07

Similar Documents

Publication Publication Date Title
BE1001068A4 (fr) Methode d'ouverture rapide de fichiers a disques identifies par la denomination de chemins.
US9189493B2 (en) Object file system
US7958310B2 (en) Apparatus, system, and method for selecting a space efficient repository
EP1918822A1 (fr) Système et procédé d'indexation de mémoire
EP2350836B1 (fr) Dispositif pour gerer des tampons de donnees dans un espace memoire reparti sur une pluralite d'elements de memoire
FR2846460A1 (fr) Procedes de lecture et d'ecriture d'une memoire flash
EP3586221B1 (fr) Procédé, équipement et système de gestion du système de fichiers
EP1483673A1 (fr) Methode de stockage de blocs de donnees dans une memoire
WO2008113921A2 (fr) Procede de gestion de fichiers
EP1849054A1 (fr) Dispositif de stockage de donnees
WO2018046850A1 (fr) Methodes et dispositifs pour contourner le cache interne d'un controleur memoire dram evolue
FR3084496A1 (fr) Procede et dispositif de generation d'instructions destinees a un dispositif pour realiser une mise a jour sur place d'un fichier de donnees
FR3082974A1 (fr) Procede de gestion de panne dans un reseau de nœuds base sur une strategie globale
WO2006016085A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
EP2990948B1 (fr) Nuage de donnees
FR3001818A1 (fr) Dispositif de stockage redondant securise et procede de lecture ecriture securise sur un tel dispositif
FR3084497A1 (fr) Procede et dispositif de generation d'instructions destinees a un dispositif pour mettre a jour sur place un fichier de donnees
EP1728164B1 (fr) Procede pour l'emulation logicielle de disques durs d'une plate-forme informatique au niveau du systeme d'exploitation avec gestion parametrable a la volee des requetes d'ecriture et de lecture
US10063256B1 (en) Writing copies of objects in enterprise object storage systems
CN111435342A (zh) 海报的更新方法、更新系统以及管理系统
FR2842623A1 (fr) Procede de traduction d'un message d'un premier langage de balisage dans un second langage de balisage
WO2019129998A1 (fr) Accès multiples à un fichier de données stocké dans un système de stockage de données associé à un espace mémoire tampon
WO2019129958A1 (fr) Procede de stockage de donnees et procede d'execution d'application avec reduction du temps d'acces aux donnees stockees
WO2017109435A1 (fr) Procede de configuration d'un systeme d'exploitation
CN1395246A (zh) 虚拟镜像光盘盘片的实现方法及其系统硬件结构

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200131

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6