This pull request introduces a configurable option to override the default initial IO record size used when reading records from disk, allowing users to tune disk read behavior for different workloads. The change propagates this setting from configuration files and server options down to the storage engine and replaces the previous hardcoded constant with a default value that can be overridden at the store, session, or operation level. Additional refactoring improves naming and documentation for clarity.

Configuration and Settings Changes:

• Added a new InitialIORecordSize option to Options, GarnetServerOptions, and the default configuration file, allowing users to specify the initial read size for records on disk. This setting accepts memory size strings (e.g., "4k", "8k") and defaults to 32 bytes if not set. [1] [2] [3]
• Updated the settings propagation so that InitialIORecordSize is passed through from configuration to internal KVSettings, including parsing and validation logic. [1] [2] [3]

Storage Engine and API Changes:

• Replaced the old IStreamBuffer.InitialIOSize constant with IStreamBuffer.DefaultInitialIORecordSize, and updated all usages and documentation for clarity and flexibility. [1] [2] [3] [4] [5]
• Extended the client session API to allow specifying InitialIORecordSize at the session and per-operation level, ensuring that the IO record size can be fine-tuned for different access patterns. [1] [2] [3] [4] [5]
• Increased the minimum log page size from 512 bytes to 4kb and revised tests accordingly, which in many cases required changing expected log addresses, object counts, etc.
• Modified the device sector size setting to be the max of 512 or the device's reported logical sector size.

Garnet test fixes:

• Fixed intermittent hang (due to LASTSAVE having only one-second resolution) when waiting for checkpoint completion.

Internal Refactoring and Documentation:

• Improved naming and documentation throughout the storage engine to clarify the purpose and usage of the initial IO record size, and added a utility method to compute expected record sizes for IO. [1] [2] [3] [4]

These changes make the system more flexible and performant by allowing better control over disk IO behavior, which can be critical for optimizing latency and throughput under different workloads.