When a system is down due to panic and so on, data must be resynchronized between the disk units after reboot (after cluster application failover for a cluster system).
Although the user can run an application during this copying process, redundancy will be lost and loads will be imposed during the process.
In order to resolve this problem, GDS offers a mechanism called Just Resynchronization Mechanism (JRM). JRM can complete copying, which usually takes a few minutes for each 1 GB, by quickly copying only portions where data mirrored by synchronization is not retained.
Figure 1.11 Just Resynchronization Mechanism (JRM)
Information
What is JRM?
JRM stands for Just Resynchronization Mechanism, a feature that only allows duplication of the damaged part of data.
Information
Three Types of JRM
There are three types of Just Resynchronization Mechanism (JRM): for volumes, for slices and for proxy. For details, see "A.4 Just Resynchronization Mechanism (JRM)."
Note
Root File System Volume Resynchronization [EFI]
Even when the OS is shut down normally, access from the OS to the root file system (/) volume is not canceled. For this reason, at server startup, resynchronization of the root (/) volume is always performed.
