Is this a question, feature request, or bug report?
FEATURE REQUEST
Please describe the feature you are requesting.
Its well known practice to send hints down to inform application intent to the io stack. T10 has came up with many of these features, and fadvise() and madvise() were introduced to the linux kernel. While there is a huge debate in the Linux community on the pervasiveness and the proper semantics of these hints, it is undeniable fact that the IO stack can do wonders if it has better context and information about the application intent.
Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?
Must have for Salesforce; may be nice to have for the community
Provide any additional detail on your proposed use case for this feature.
Current bookkeper storage model is monolithic. It threats all ledgers in the same way.
If we have a way for the application to express its interest on:
Latency focused vs throughput focused
EntryId level consistency vs Ledger level consistency.
Data temperature. HOT/COLD
IO access pattern random vs sequential.
Knowing this information allows stack to make many adjustments to serve the application well.
None of this should affect the correctness or guarantees offered, but rather viewed as performance and cost optimizations. Well one exception to the guarantee is consistency boundary (entry vs ledger)
If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:
Is this a question, feature request, or bug report?
FEATURE REQUEST
Its well known practice to send hints down to inform application intent to the io stack. T10 has came up with many of these features, and fadvise() and madvise() were introduced to the linux kernel. While there is a huge debate in the Linux community on the pervasiveness and the proper semantics of these hints, it is undeniable fact that the IO stack can do wonders if it has better context and information about the application intent.
Must have for Salesforce; may be nice to have for the community
Current bookkeper storage model is monolithic. It threats all ledgers in the same way. If we have a way for the application to express its interest on:
Knowing this information allows stack to make many adjustments to serve the application well. None of this should affect the correctness or guarantees offered, but rather viewed as performance and cost optimizations. Well one exception to the guarantee is consistency boundary (entry vs ledger)