WO2010043245A1 - Verfahren zur sicherung eines ankerblocks in flashspeichern - Google Patents

Verfahren zur sicherung eines ankerblocks in flashspeichern Download PDF

Info

Publication number
WO2010043245A1
WO2010043245A1 PCT/EP2008/063748 EP2008063748W WO2010043245A1 WO 2010043245 A1 WO2010043245 A1 WO 2010043245A1 EP 2008063748 W EP2008063748 W EP 2008063748W WO 2010043245 A1 WO2010043245 A1 WO 2010043245A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
anchor block
anchor
flash memory
copy
Prior art date
Application number
PCT/EP2008/063748
Other languages
English (en)
French (fr)
Inventor
Franz Schmidberger
Christoph Baumhof
Christian Senger
Original Assignee
Hyperstone Gmbh
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 Hyperstone Gmbh filed Critical Hyperstone Gmbh
Priority to PCT/EP2008/063748 priority Critical patent/WO2010043245A1/de
Publication of WO2010043245A1 publication Critical patent/WO2010043245A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1666—Error detection or correction of the data by redundancy in hardware where the redundant component is memory or memory area
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements

Definitions

  • the invention relates to a method for securing a block, identified as an anchor block, of an erasable block-organized flash memory in which management data of the flash memory is stored.
  • the data structure in which the characterizing data of the memory and other management information are stored is stored in the so-called anchor block.
  • the anchor block is the first non-defective block on chip 0 of the flash memory. Since the manufacturers of the chips guarantee the functionality of block 0, the anchor block is on chip 0 in block 0. In previous flash memories, the anchor block is present only once. Therefore, it was not allowed to delete this block after the initial formatting of the storage system and then overwrite it again.
  • the anchor block contains static data and can only be read.
  • the method provides that a copy is written by the anchor block in a free block of the flash memory and is rewritten in case of errors in the read operations from the anchor block, this with the contents of the backup copy. With the deletion and subsequent overwriting of the anchor block this is refreshed and can continue to be used without read error.
  • the method is simplified by storing the anchor block, which is typically stored in the first block of the first memory chip, as well as the backup copy in the first 128 blocks of a memory. These 128 blocks are called here the base page of the memory. If a copy of the anchor block is to be searched or written, the search for this block is limited to the base page and can be done quickly.
  • An anchor block counter is included in the anchor block, which is incremented each time a backup copy is made. In the original anchor block, this counter is set to 1, indicating that a backup exists. If the content of the anchor block counter is 0, it indicates that no backup copy is provided.
  • An anchor block is marked by a magic number at the beginning of the block. This is 0x12345678 in one implementation. It is very unlikely that this magic number will be read at the beginning of a block other than the anchor block. Thus, the search for an anchor block or its backup very easy.
  • a pointer is included in the anchor block at a fixed position, which points to the end position of the described region of the anchor block.
  • the content of the anchor block can be checked very easily. It does not have the entire block be checked.
  • This anchor block counter has the value 1 in the first anchor block.
  • Anchor block used to manage the flash memory.
  • the newly written block is used as a backup copy and the previous backup as an anchor block.
  • the method for writing a new anchor block must also be against a
  • a new startup of the flash memory such as after a power failure, will search for a valid anchor block. This will be the base page after blocks with the magic
  • Block is checked for read errors up to the position indicated by the end pointer.
  • Fig. 1 shows a block diagram of a flash memory system.
  • Fig. 2 shows a flow chart of the overwriting of the anchor block.
  • Fig. 3 shows a flowchart in a writing error.
  • FIG. 4 shows a flowchart for determining the anchor block during system startup.
  • FIG. 1 shows a flash memory 1 which contains a memory controller 2 and a plurality of flash chips 3 and 7.
  • the base side 6 is provided, in which the anchor block 4 and the backup copy 5 are accommodated.
  • the memory controller 2 reads data from the anchor block 4. If read errors occur, the anchor block 4 is overwritten by the memory controller with the contents of the backup copy 5. Thereafter, the memory controller 2 can work again without errors.
  • the read operation and the overwriting of the anchor block are illustrated in FIG. If read errors occur while reading from the anchor block, a check is made as to whether a backup exists. This is known from the entry for the anchor block counter. If there is no backup, there is a critical memory system error. Otherwise, the anchor block is overwritten and thus refreshed, so that initially no more read errors occur. It continues to read from the anchor block.
  • FIG. 3 shows how errors in overwriting the anchor block are traversed. If write errors occur, the base page looks for a free block that can serve as the anchor block. If there is no free block, the block with the lowest number of deletes carried in each block is searched in the base page. Its contents are copied to a free block in the storage system and then the block is deleted. It is thus available as a block for the anchor block. The anchor block counter AB is incremented and the new anchor block is described with the contents of the backup copy.
  • FIG. 4 shows a system startup of the memory system, for example after a power failure.
  • An address pointer ADR is set to 0 and an anchor block number AC is set to -1.
  • the blocks of the base side are then examined successively for the magic number. If the magic number is found, the memory contents of this block are checked for accuracy. If there is no error, it is checked whether the value of the Ankerblockweakeneders AB of this block is greater than the noted anchor block number AC. If so, the anchor block address AA is taken from the address pointer ADR and the anchor block number from the current anchor block counter AB. The search for the anchor blocks is continued with incremented address pointer ADR.
  • the anchor block number is greater than -1 and the valid address of the anchor block is noted in the anchor block address AA. This block can now be used as an anchor block.
  • the method described here avoids a failure of the armature block of a flash memory system and thus substantially increases the reliability of such a memory system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

Die Erfindung beschreibt ein Verfahren zur Sicherung eines als Ankerblock gekennzeichneten Blockes eines in löschbaren Blöcken organisierten Flashspeichers, in dem Verwaltungsdaten des Flashspeichers gespeichert sind, wobei - eine Sicherungskopie (5) des Ankerblocks (4) in einen freien Block des Flashspeichers (1) geschrieben wird - und bei auftretenden Fehlern bei den Leseoperationen aus dem Ankerblock (4) dieser mit dem Inhalt der Sicherungskopie (5) neu geschrieben wird.

Description

Verfahren zur Sicherung eines Ankerblocks in Flashspeichern
Die Erfindung betrifft ein Verfahren zur Sicherung eines als Ankerblock gekennzeichneten Blockes eines in löschbaren Blöcken organisierten Flashspeichers, in dem Verwaltungsdaten des Flashspeichers gespeichert sind.
In einem Flashspeicher wird die Datenstruktur, in der die kennzeichnenden Daten des Speichers und weitere Verwaltungsinformationen gespeichert sind, in dem so genannten Ankerblock gespeichert. Dieser enthält Informationen über die Struktur des Speichersystems und wo die Firmware für das Speichersystem gefunden werden kann. Dies sind kritische Daten für die Funktionsfähigkeit des Speichersystems. Üblicherweise ist der Ankerblock der erste nicht-defekte Block auf dem Chip 0 des Flashspeichers. Da die Hersteller der Chips die Funktionsfähigkeit des Blocks 0 garantieren, befindet sich der Ankerblock auf Chip 0 in Block 0. In bisherigen Flashspeichern ist der Ankerblock nur einmal vorhanden. Daher war es nicht erlaubt, diesen Block nach der initialen Formatierung des Speichersystems zu löschen und dann wieder zu überschreiben. Der Ankerblock enthält statische Daten und kann nur gelesen werden.
In der Vergangenheit wurden nun viele Flashspeicher gefunden, bei denen die Integrität der Daten des Ankerblocks durch das so genannte „read disturb" verloren ging. Da der Flashspeicher sich wie eine Festplatte in einem Computer verhalten soll, greift das Betriebssystem des Computers häufig auf die Daten des Ankerblocks zu. Auch wird die Firmware des Flashspeichersystems zunehmend komplex und da durch die Speicherbegrenzung des Speichercontrollers Firmware aus dem Ankerblock immer wieder nachgeladen werden muss, wird der Ankerblock sehr häufig gelesen und es kann zu read-disturb-Fehlern kommen. Es ist die Aufgabe der Erfindung, ein Verfahren zu offenbaren, das read-disturb-Fehler beim Lesen des Ankerblocks in Flashspeichern vermeidet und damit die Zuverlässigkeit des Speichersystems erhöht.
Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen des Verfahrens sind in den Unteransprüchen beschrieben.
Das Verfahren sieht vor, dass von dem Ankerblock eine Kopie in einen freien Block des Flashspeichers geschrieben wird und bei auftretenden Fehlern bei den Leseoperationen aus dem Ankerblock dieser mit dem Inhalt der Sicherungskopie neu geschrieben wird. Mit dem Löschen und anschließenden Überschreiben des Ankerblocks wird dieser aufgefrischt und kann ohne Lesefehler weiter genutzt werden.
Das Verfahren wird vereinfacht, indem der Ankerblock, der typischerweise in dem ersten Block des ersten Speicherchips gespeichert ist, sowie die Sicherungskopie in den ersten 128 Blöcken eines Speichers gespeichert sind. Diese 128 Blöcke werden hier die Basisseite des Speichers genannt. Falls nun eine Kopie des Ankerblocks gesucht oder geschrieben werden soll, ist die Suche nach diesem Block auf die Basisseite begrenzt und kann schnell erfolgen.
In dem Ankerblock wird ein Ankerblockzähler mitgeführt, der bei jedem Schreiben einer Sicherungskopie inkrementiert wird. In dem ursprünglichen Ankerblock wird dieser Zähler auf 1 gesetzt und gibt damit auch an, dass eine Sicherungskopie existiert. Wenn der Inhalt des Ankerblockzählers auf 0 steht, gibt dies an, dass keine Sicherungskopie vorgesehen ist.
Ein Ankerblock ist durch eine magische Zahl am Anfang des Blockes gekennzeichnet. Diese lautet in einer Ausführung 0x12345678. Es ist sehr unwahrscheinlich, dass diese magische Zahl am Anfang eines anderen Blockes als dem Ankerblock gelesen wird. Somit die Suche nach einem Ankerblock oder seiner Sicherungskopie sehr einfach.
Weiterhin ist in dem Ankerblock an einer festgelegten Position ein Zeiger enthalten, der auf die Endposition des beschriebenen Bereichs des Ankerblocks weist. Somit kann der Inhalt des Ankerblocks sehr einfach überprüft werden. Es muss nicht der gesamte Block überprüft werden.
Es kann nun vorkommen, dass bei einem erneuten Überschreiben des Ankerblocks ein
Fehler auftritt. In diesem Fall wird ein gelöschter Block in der Basisseite gesucht, der als neuer Ankerblock dienen kann. Wenn ein solcher gefunden wird, wird er mit dem
Inhalt der Sicherungskopie und einem inkrementierten Ankerblockzähler beschrieben.
Dieser Ankerblockzähler besitzt in dem ersten Ankerblock den Wert 1.
Wenn in der Basisseite kein gelöschter Block vorhanden ist, wird dort der Block gesucht, der bisher am seltensten überschrieben wurde. Dies wird über bekannte Löschzähler ermittelt. Sein Inhalt wird in einen anderen freien Block kopiert. Dann wird der Block in der Basisseite gelöscht und mit dem Inhalt der Sicherungskopie und einem inkrementierten Ankerblockzähler beschrieben. Dieser Block wird nun als neuer
Ankerblock zur Verwaltung des Flashspeichers genutzt.
Es ist aber auch möglich, dass der neu geschriebene Block als Sicherungskopie und die bisherige Sicherungskopie als Ankerblock genutzt wird.
Das Verfahren zum Schreiben eines neuen Ankerblockes muss auch gegen einen
Ausfall des Speichersystems beim Kopiervorgang gesichert sein.
Bei einem neuen Anlauf des Flashspeichers, etwa nach einem Stromausfall, wird ein gültiger Ankerblock gesucht. Dazu wird die Basisseite nach Blöcken mit der magischen
Zahl durchsucht. Bei jedem Block mit dieser magischen Zahl wird der Inhalt des
Blockes bis zu der durch den End-Zeiger bezeichneten Position auf Lesefehler geprüft.
Wenn mehrere solcher Blöcke gefunden wurden, wird der Block mit dem höchsten
Wert des Ankerblockzählers als Ankerblock genutzt. Somit ist sichergestellt, dass mit einer aktuellen und fehlerfreien Version des Ankerblocks gearbeitet wird.
Ausführungsformen der Erfindung sind in den Figuren beispielhaft beschrieben. Fig. 1 zeigt ein Blockdiagramm eines Flashspeichersystems. Fig. 2 zeigt ein Ablaufdiagramm des Überschreibens des Ankerblocks. Fig. 3 zeigt ein Ablaufdiagramm bei einem Schreibfehler.
Fig. 4 zeigt ein Ablaufdiagramm zur Bestimmung des Ankerblocks beim Systemanlauf. In Fig. 1 ist ein Flashspeicher 1 dargestellt, der einen Speichercontroller 2 und mehrere Flashchips 3 und 7 enthält. In dem ersten Flashchip 3 ist mit den ersten 128 Blöcken die Basisseite 6 vorhanden, in der der Ankerblock 4 und die Sicherungskopie 5 untergebracht sind. Der Speichercontroller 2 liest Daten aus dem Ankerblock 4. Falls Lesefehler auftreten, wird der Ankerblock 4 durch den Speichercontroller mit dem Inhalt der Sicherungskopie 5 überschrieben. Danach kann der Speichercontroller 2 wieder fehlerfrei arbeiten.
Der Lesevorgang und das Überschreiben des Ankerblocks sind in Fig. 2 veranschaulicht. Wenn beim Lesen aus dem Ankerblock Lesefehler auftreten, wird geprüft, ob eine Sicherungskopie vorhanden ist. Dies ist anhand des Eintrags für den Ankerblockzähler bekannt. Falls keine Sicherungskopie vorhanden ist, liegt ein kritischer Fehler des Speichersystems vor. Ansonsten wird der Ankerblock überschrieben und damit aufgefrischt, so dass zunächst keine Lesefehler mehr vorkommen. Es wird mit dem Lesen aus dem Ankerblock fortgefahren.
In Fig. 3 ist dargestellt, wie bei Fehlern beim Überschreiben des Ankerblocks verfahren wird. Wenn Schreibfehler auftreten, wird in der Basisseite nach einem freien Block gesucht, der als Ankerblock dienen kann. Wenn kein freier Block vorhanden ist, wird der Block mit der niedrigsten Löschzahl, die in jedem Block mitgeführt wird, in der Basisseite gesucht. Dessen Inhalt wird in einen freien Block im Speichersystem kopiert und dann der Block gelöscht. Er steht somit als Block für den Ankerblock zur Verfügung. Der Ankerblockzähler AB wird inkrementiert und der neue Ankerblock wird mit dem Inhalt der Sicherungskopie beschrieben.
In Fig. 4 ist ein Systemanlauf des Speichersystems, zum Beispiel nach einem Stromausfall, dargestellt. Ein Adresszeiger ADR wird auf 0 gesetzt und eine Ankerblocknummer AC auf -1. Mittels des Adresszeigers ADR werden nun die Blöcke der Basisseite der Reihe nach auf die magische Zahl untersucht. Wenn die magische Zahl gefunden wird, wird der Speicherinhalt dieses Blockes auf Fehlerfreiheit geprüft. Falls kein Fehler vorliegt, wird geprüft, ob der Wert des Ankerblockzählers AB dieses Blockes größer ist als die gemerkte Ankerblocknummer AC. Wenn dies der Fall ist, wird die Ankerblockadresse AA aus dem Adresszeiger ADR und die Ankerblocknummer aus dem aktuellen Ankerblockzähler AB übernommen. Die Suche nach den Ankerblöcken wird mit inkrementiertem Adresszeiger ADR fortgesetzt. Wenn alle 128 Blöcke der Basisseite durchsucht sind, wird geprüft, ob ein gültiger Ankerblock gefunden wurde. In diesem Fall ist die Ankerblocknummer größer als -1 und die gültige Adresse des Ankerblockes ist in der Ankerblockadresse AA vermerkt. Dieser Block kann nun als Ankerblock genutzt werden.
Wurde kein gültiger Ankerblock gefunden, liegt ein kritischer Fehler des Speichersystems vor.
Mit den hier beschriebenen Verfahren wird ein Ausfall des Ankerblocks eines Flashspeichersystems vermieden und damit die Zuverlässigkeit eines solchen Speichersystems wesentlich erhöht.
_ _
Bezugszeichen:
1 Flashspeicher
2 Speichercontroller
3 Flashchip
4 Ankerblock
5 Sicherungskopie
6 Basisseite
7 weitere Flashchips
AA Adresse eines gültigen Ankerblocks
AB Ankerblockzähler
AC Ankerblocknummer
ADR Adresse auf einen Block der Basisseite

Claims

Ansprüche:
1. Verfahren zur Sicherung eines als Ankerblock gekennzeichneten Blockes eines in löschbaren Blöcken organisierten Flashspeichers, in dem Verwaltungsdaten des Flashspeichers gespeichert sind, dadurch gekennzeichnet, dass
- eine Sicherungskopie (5) des Ankerblocks (4) in einen freien Block des Flashspeichers (1) geschrieben wird
- und bei auftretenden Fehlern bei den Leseoperationen aus dem Ankerblock (4) dieser mit dem Inhalt der Sicherungskopie (5) neu geschrieben wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Ankerblock (4) und seine Sicherungskopien (5) in einer Basisseite (3), bestehend aus den ersten 128 Blöcken des Flashspeichers, gespeichert sind.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass in dem Ankerblock und der Sicherungskopie ein Ankerblockzähler (AB) geführt wird, der in dem ersten Ankerblock den Wert 1 besitzt.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Ankerblock durch eine magische Zahl am Anfang des Blockes sowie durch einen End-Zeiger auf die letzte im Ankerblock beschriebene Position gekennzeichnet ist.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die magische Zahl 0x12345678 lautet.
6. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass
- wenn der Ankerblock nicht wieder neu beschrieben werden kann,
- ein gelöschter Block in der Basisseite gesucht wird
- und falls dort kein Block gelöscht ist, dort der Block gesucht wird, der am seltensten überschrieben wurde,
- dieser Block in einen andern Block des Flashspeichers kopiert und dann gelöscht wird,
- und dann in den gelöschten Block eine neue Kopie des Ankerblocks mit einem inkrementierten Ankerblockzähler geschrieben wird
- und dann diese Kopie als Ankerblock genutzt wird.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass bei einem neuen Anlauf des Flashspeichers ein gültiger Ankerblock gesucht wird, indem
- die Basisseite nach Blöcken mit der magischen Zahl durchsucht wird
- und wenn ein solcher Block gefunden wird, der Inhalt des Ankerblockes bis zu der durch den End-Zeiger gekennzeichneten Position auf Lesefehler geprüft wird
- und die fehlerfreie Kopie des Ankerblockes mit dem höchsten Wert in dem Ankerblockzähler (AB) als Ankerblock genutzt wird.
PCT/EP2008/063748 2008-10-13 2008-10-13 Verfahren zur sicherung eines ankerblocks in flashspeichern WO2010043245A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/063748 WO2010043245A1 (de) 2008-10-13 2008-10-13 Verfahren zur sicherung eines ankerblocks in flashspeichern

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/063748 WO2010043245A1 (de) 2008-10-13 2008-10-13 Verfahren zur sicherung eines ankerblocks in flashspeichern

Publications (1)

Publication Number Publication Date
WO2010043245A1 true WO2010043245A1 (de) 2010-04-22

Family

ID=40467407

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/063748 WO2010043245A1 (de) 2008-10-13 2008-10-13 Verfahren zur sicherung eines ankerblocks in flashspeichern

Country Status (1)

Country Link
WO (1) WO2010043245A1 (de)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000049488A1 (en) * 1999-02-17 2000-08-24 Memory Corporation Plc Memory system
US6728913B1 (en) * 2000-02-25 2004-04-27 Advanced Micro Devices, Inc. Data recycling in memory
US20040156251A1 (en) * 2003-02-07 2004-08-12 Renesas Technology Corp. Nonvolatile memory system
EP1693739A1 (de) * 2001-09-28 2006-08-23 Lexar Media, Inc. Verfahren zum Schreiben von Daten in einen nicht flüchtigen Speicher
US20060242460A1 (en) * 2002-08-16 2006-10-26 Sreenath Mambakkam Software recovery method for flash media with defective formatting
US20080055989A1 (en) * 2006-09-06 2008-03-06 Kyoong-Han Lee Memory system including flash memory and method of operating the same
JP2008192266A (ja) * 2007-02-07 2008-08-21 Megachips Lsi Solutions Inc メモリコントローラ

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000049488A1 (en) * 1999-02-17 2000-08-24 Memory Corporation Plc Memory system
US6728913B1 (en) * 2000-02-25 2004-04-27 Advanced Micro Devices, Inc. Data recycling in memory
EP1693739A1 (de) * 2001-09-28 2006-08-23 Lexar Media, Inc. Verfahren zum Schreiben von Daten in einen nicht flüchtigen Speicher
US20060242460A1 (en) * 2002-08-16 2006-10-26 Sreenath Mambakkam Software recovery method for flash media with defective formatting
US20040156251A1 (en) * 2003-02-07 2004-08-12 Renesas Technology Corp. Nonvolatile memory system
US20080055989A1 (en) * 2006-09-06 2008-03-06 Kyoong-Han Lee Memory system including flash memory and method of operating the same
JP2008192266A (ja) * 2007-02-07 2008-08-21 Megachips Lsi Solutions Inc メモリコントローラ
US20080259708A1 (en) * 2007-02-07 2008-10-23 Megachips Corporation Memory controller

Similar Documents

Publication Publication Date Title
DE112011100112B4 (de) Pufferspeicher-platte in blitzkopie-kaskade
DE60217883T2 (de) Verfahren zum schreiben von daten in einen nicht-flüchtigen speicher
DE112011100534B4 (de) Mehrstufiger Sicherungsprozess
DE112010003887B4 (de) Datenverwaltung in Halbleiter-Speichereinheiten
DE69034227T2 (de) EEprom-System mit Blocklöschung
DE60213867T2 (de) Vorrichtung zur verwaltung von datenreplikation
DE60008929T2 (de) Schnellstart eines mikroprozessorbasierten systems
DE102012208141B4 (de) Ausgleich nachlassender Funktionsfähigkeit
DE112007003015B4 (de) Verfahren und Vorrichtung zur Cache-gestützten Fehlerdetektion und -korrektur in einem Speicher
DE102011075814B4 (de) Speicherpuffer mit zugänglicher Information nach einem Schreibfehler
DE112008000180T5 (de) Verfahren und System für die Umsetzung eines Fast-Wakeup eines Flashspeichersystems
DE112015004873T5 (de) Verarbeitung von Entabbildungsbefehlen zur Verbesserung der Leistungsfähigkeit und Standzeit einer Speicherungsvorrichtung
DE102016010277A1 (de) Verfahren und systeme zum verbessern von speicher-journaling
DE112006001636T5 (de) Technik zum Beschreiben eines nicht-flüchtigen Speichers
DE10297281T5 (de) Verfahren zum elementaren Aktualisieren einer Vielzahl von Dateien
DE102005028827A1 (de) Flashspeicherbauelement und Verfahren zur Defektblockbehandlung
DE112010003577T5 (de) Datenverwaltung in Halbleiterspeicher-Einheiten und mehrstufigen Speichersystemen
DE102009031923A1 (de) Verfahren zum Verwalten von Datenobjekten
DE69820164T2 (de) Speichervorrichtung sowie Datenlese- und Schreibverfahren
DE102013021679A1 (de) Rettung von Ereignisnachverfolgungsinformationen bei Stromausfall-Unterbrechungsszenarien
DE102017112489B4 (de) Journalisiertes replay mit mehreren streams
DE602004007925T2 (de) Verwalten einer beziehung zwischen einem zielvolumen und einem quellenvolumen
DE102006036070A1 (de) Ladungsfallenspeichervorrichtung und Verfahren für deren Herstellung und Betrieb
US8019953B2 (en) Method for providing atomicity for host write input/outputs (I/Os) in a continuous data protection (CDP)-enabled volume using intent log
DE102005012358A1 (de) Datenschutz unter Verwendung von Daten, die in Schnappschüsse verteilt sind

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08805261

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08805261

Country of ref document: EP

Kind code of ref document: A1