mirror of
https://github.com/ostreedev/ostree.git
synced 2024-12-22 17:35:55 +03:00
2c39bd88a9
This is trying to address: https://pagure.io/fedora-iot/issue/48 Basically we changed rpm-ostree to start doing a shared lock during commit by default, but this broke because pungi is starting a process doing a commit for each architecture, and then trying to regenerate the summary after each one. This patch is deleting a big comment with a rationale for why summary regeneration should be exclusive. Point by point: > This makes sure the commits and deltas don't get > deleted while generating the summary. But prune operations require an exclusive lock, which means that data still can't be deleted when the summary grabs a shared lock. > It also means we can be sure refs > won't be created/updated/deleted during the operation, without having to > add exclusive locks to those operations which would prevent concurrent > commits from working. First: The status quo *has* prevented concurrent commits from working! There is no real locking solution to this problem. What we really need to do here is regenerate the summary after each commit *or* when the caller decides to do it and e.g. include deltas at the same time. It's OK if multiple threads race to regenerate the summary; last-one-wins behavior here is totally fine. |
||
|---|---|---|
| .. | ||
| boot | ||
| libostree | ||
| libotutil | ||
| ostree | ||
| rofiles-fuse | ||
| switchroot | ||