Browse Prior Art Database

METHOD AND MEANS OF ENSURING DATA INTEGRITY WITH REMOVABLE NVRAM CACHE

IP.com Disclosure Number: IPCOM000014790D
Original Publication Date: 2000-Mar-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 1 page(s) / 38K

Publishing Venue

IBM

Abstract

When a customer is running their RAID adapter in write-back mode, with an NVRAM cache, and the NVRAM cache fails, what do we do? First thing we do is stop using the NVRAM cache, otherwise, it might ultimately hang the system. But now we have a data integrity exposure. Problem #1 is that if the system is powered off in write-back mode, then we will lose the dirty data that has not been flushed. This disclosure addresses that problem (and its follow-on) by proposing a method which notifies the user of the NVRAM cache failure, automatically flushes all dirty data to disk, and switches the system to write-through mode until the next time the system is rebooted. This solves the immediate exposure. However, it brings to light Problem #2. When the system is rebooted, the NVRAM cache will have data in it (as we totally stopped using it as soon as we had a failure). This, however, is stale data, now. If the NVRAM cache problem was intermittent, and I try to talk to it on reboot, it may very well talk to me now, and allow me to reconstruct this stale data. Data written while in write-through mode may be overwritten. To address this problem, the NVRAM failure is stored in the configuration. On reboot, the configuration is checked, and if the NVRAM cache was previously defective and has not been replaced, no data will be reconstructed and once again, the system will automatically switch to write-through mode.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 68% of the total text.

Page 1 of 1

  METHOD AND MEANS OF ENSURING DATA INTEGRITY WITH REMOVABLE NVRAM CACHE

When a customer is running their RAID adapter in write-back mode, with an NVRAM cache, and the NVRAM cache fails, what do we do? First thing we do is stop using the NVRAM cache, otherwise, it might ultimately hang the system. But now we have a data integrity exposure. Problem #1 is that if the system is powered off in write-back mode, then we will lose the dirty data that has not been flushed. This disclosure addresses that problem (and its follow-on) by proposing a method which notifies the user of the NVRAM cache failure, automatically flushes all dirty data to disk, and switches the system to write-through mode until the next time the system is rebooted. This solves the immediate exposure. However, it brings to light Problem #2. When the system is rebooted, the NVRAM cache will have data in it (as we totally stopped using it as soon as we had a failure). This, however, is stale data, now. If the NVRAM cache problem was intermittent, and I try to talk to it on reboot, it may very well talk to me now, and allow me to reconstruct this stale data. Data written while in write-through mode may be overwritten. To address this problem, the NVRAM failure is stored in the configuration. On reboot, the configuration is checked, and if the NVRAM cache was previously defective and has not been replaced, no data will be reconstructed and once again, the system will automatically switch to write-through m...