Record Store, Versionstamp and Cluster Migration

I have two questions regarding cluster migration of record stores.

  1. Is there some way in which the record stores can be put into “maintenance” mode prior to performing cluster migration?

  2. As I was reading SplitHelper code, I realized every record is stored with a versionstamp at -1 entry. In the record layer paper, the term “incarnation” is mentioned when describing VERSION index.

I was looking at the record store header protobuf definition.

message DataStoreInfo {
  optional int32 formatVersion = 1;
  optional int32 metaDataversion = 2;
  optional int32 userVersion = 3;
  optional KeyExpression record_count_key = 4;
  optional uint64 lastUpdateTime = 5;
  optional bool omit_unsplit_record_suffix = 6;
  optional bool cacheable = 7;

  // Compatible with map<string, bytes> on the wire
  message UserFieldEntry {
    optional string key = 1;
    optional bytes value = 2;
  repeated UserFieldEntry user_field = 8;

I was unable to figure out where the “incarnation” and possibly “maintenance state” information is stored?

Is it something that is maintained in UserFieldEntry outside of RL?