344
Application Utilization of Data Loss Count (DLC)
Applications may want to use the DLC counter provided by _NBS to detect if possible
data loss occurred while saving data from the system’s persistence domain to the
persistent media. If such a loss can be detected, applications can perform data recovery
or rollback using application-specific features.
The application’s responsibilities and possible implementation suggestions for
applications are outlined as follows:
1. Application first creates its initial metadata and stores it in a
persistent memory file:
a. Application retrieves current DLC via operating system–specific
means for the physical persistent memory that make up the
logical volume the applications metadata resides on.
b. Application calculates the current Logical Data Loss Count
(LDLC) as the sum of the DLC for all physical persistent memory
that make up the logical volume the applications metadata
resides on.
c. Application stores the current LDLC in its metadata file and
ensures that the update of the LDLC has been flushed to the
system’s persistence domain. This is done by using a flush that
forces the write data all the way to the persistent memory powerfail safe domain. (Chapter 2 contains more information about
flushing data to the persistence domain.)
d. Application determines GUID or UUID for the logical volume
the applications metadata resides on, stores this in its metadata
file, and ensures the update of the GUID/UUID to the persistence
domain. This is used by the application to later identify if the
metadata file has been moved to another logical volume, where
the current DLC is no longer valid.
e. Application creates and sets a “clean” flag in its metadata file and
ensures the update of the clean flag to the persistence domain.
This is used by the application to determine if the application was
actively writing data to persistence during dirty shutdown.
Chapter 17 reliability, availability, and ServiCeability (raS)
Application Utilization of Data Loss Count (DLC)
Applications may want to use the DLC counter provided by _NBS to detect if possible
data loss occurred while saving data from the system’s persistence domain to the
persistent media. If such a loss can be detected, applications can perform data recovery
or rollback using application-specific features.
The application’s responsibilities and possible implementation suggestions for
applications are outlined as follows:
1. Application first creates its initial metadata and stores it in a
persistent memory file:
a. Application retrieves current DLC via operating system–specific
means for the physical persistent memory that make up the
logical volume the applications metadata resides on.
b. Application calculates the current Logical Data Loss Count
(LDLC) as the sum of the DLC for all physical persistent memory
that make up the logical volume the applications metadata
resides on.
c. Application stores the current LDLC in its metadata file and
ensures that the update of the LDLC has been flushed to the
system’s persistence domain. This is done by using a flush that
forces the write data all the way to the persistent memory powerfail safe domain. (Chapter 2 contains more information about
flushing data to the persistence domain.)
d. Application determines GUID or UUID for the logical volume
the applications metadata resides on, stores this in its metadata
file, and ensures the update of the GUID/UUID to the persistence
domain. This is used by the application to later identify if the
metadata file has been moved to another logical volume, where
the current DLC is no longer valid.
e. Application creates and sets a “clean” flag in its metadata file and
ensures the update of the clean flag to the persistence domain.
This is used by the application to determine if the application was
actively writing data to persistence during dirty shutdown.
Chapter 17 reliability, availability, and ServiCeability (raS)