Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pull: Add OSTREE_PULL_MAX_OUTSTANDING_WRITES env var #2147

Closed

Conversation

cgwalters
Copy link
Member

We need to expose more control over how fast we write to disk
in order to allow OS vendors to more finely tune latency vs
throughput for OS updates.

See openshift/machine-config-operator#1897

This is a crude hack I'm using for testing; need to also
expose this via API, document it etc.

@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jlebon
Copy link
Member

jlebon commented Jul 10, 2020

Any preliminary results on how effective this is? Feels like the better thing to throttle is size of outstanding objects instead of number of objects, though that's a bigger patch. If it unblocks openshift/machine-config-operator#1897 though, WFM! (Could probably make it a repo config knob instead/in addition?).

We need to expose more control over how fast we write to disk
in order to allow OS vendors to more finely tune latency vs
throughput for OS updates.

See openshift/machine-config-operator#1897

This `OSTREE_PULL_MAX_OUTSTANDING_WRITES` is a crude hack
I'm using for testing; need to also expose this via API, document it etc.

Second, add a `per-object-fsync` option which goes back to invoking
`fsync()` on each object just after writing it.

Combined, these two ensure natural "backpressure" against trying
to fsync a huge amount of data all at once, which I believe is
what is leading to the huge etcd fsync latency.
@cgwalters cgwalters force-pushed the pull-outstanding-writes branch from 78240d4 to 58a9c96 Compare July 15, 2020 03:45
@cgwalters cgwalters closed this Jul 16, 2020
@cgwalters
Copy link
Member Author

Moved this to #2152

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants