Gemfire: Effect of disk segmentation introduced in Gemfire 10.1.0 on custom scripts.

Products

• VMware Tanzu Gemfire

Issue/Introduction

This article addresses a couple of questions raised around disk segmentation.

1. How does custom code that relies on an internal Gemfire api call get affected by disk segmentation introduced in Gemfire 10.1.0? 
2. When Gemfire 10.1.0 starts up, is there a specific order in which it reads .crf files from the disk store?  Does it read through contents in each sub-directory before moving to the next? Or does it read file 1 in directory 0, then file 1 in directory 1, then file 1 in directory 2?

 

Environment

Gemfire 10.1.0 and above.

Resolution

In VMware GemFire 10.1.0, the introduction of Segmented Disk Stores significantly alters the physical layout and internal processing of disk store files compared to version 9.15.10.

Custom code relying on internal APIs—specifically those designed to manually parse or copy disk store files (like .crf, .drf, or .krf files) between clusters—will likely break due to changes in the directory layout. Any code that relies on the flat directory structure in previous versions will no longer work in VMware GemFire 10.1.0 where these files are organized into numbered sub-directories depending on configured segmentatuib,

As best practice, it is recommended not to use internal APIs that are subject to changes in implementation, and are not guaranteed to maintain backward compatibility.  In Gemfire, best options to copy or back up cluster are gfsh export  which abstracts the internal implementation or wan-copy. When segmented disk stores are used, the individual segments are read in parallel. The degree of parallelism is dependent on the available CPU and configuration.

When GemFire 10.1.0 starts up, it reads  CRF files (oplogs) based on their oplog ID rather than by directory order. This ensures that the state of the data is reconstructed in the exact order it was originally written.