vitalif/vitastor
5
6
Fork 12
Code Issues 4 Pull Requests 6 Actions Releases 111 Wiki Activity

fix-superblock-io-amplification #87

Merged
vitalif merged 1 commits from changwei.ye/vitastor:fix-superblock-io-amplification into master 2026-09-24 11:08:15 +03:00
Conversation 1 Commits 1 Files Changed 1 +11 -4
changwei.ye commented 2026-09-14 13:02:50 +03:00
Contributor
Copy Link

Description

fix-superblock-io-amplification

Commit df9a2850 introduced force_fsync to resolve the placement contract
conflict (EAGAIN) when a new metadata entry depends on a previous unsynced
entry that is already in-flight. However, it mistakenly grouped the
'force_fsync > 0' condition together with the Superblock Checkpoint logic.

As a result, every time the internal torn-write prevention mechanism
requested a force_fsync, the system inadvertently executed an expensive
trim_lsn() (updating the Superblock with RWF_DSYNC), causing unnecessary
write latency and I/O amplification during congested object updates.

This change minimally refactors the state machine to ensure trim_lsn() is
strictly bound to the intended journal_trim_interval, while force_fsync
only triggers the necessary fsync_buffer().

Contributor Name

Changwei Ye (Datatom, https://www.datatom.com/)

CLA

### Description fix-superblock-io-amplification Commit df9a2850 introduced force_fsync to resolve the placement contract conflict (EAGAIN) when a new metadata entry depends on a previous unsynced entry that is already in-flight. However, it mistakenly grouped the 'force_fsync > 0' condition together with the Superblock Checkpoint logic. As a result, every time the internal torn-write prevention mechanism requested a force_fsync, the system inadvertently executed an expensive trim_lsn() (updating the Superblock with RWF_DSYNC), causing unnecessary write latency and I/O amplification during congested object updates. This change minimally refactors the state machine to ensure trim_lsn() is strictly bound to the intended journal_trim_interval, while force_fsync only triggers the necessary fsync_buffer(). ### Contributor Name Changwei Ye (Datatom, https://www.datatom.com/) ### CLA - [x] I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md
changwei.ye added 1 commit 2026-09-14 13:02:51 +03:00
Store v2: decouple trim_lsn from force_fsync 73a1f622bb 
Commit df9a2850 introduced force_fsync to resolve the placement contract
conflict (EAGAIN) when a new metadata entry depends on a previous unsynced
entry that is already in-flight. However, it mistakenly grouped the
'force_fsync > 0' condition together with the Superblock Checkpoint logic.

As a result, every time the internal torn-write prevention mechanism
requested a force_fsync, the system inadvertently executed an expensive
trim_lsn() (updating the Superblock with RWF_DSYNC), causing unnecessary
write latency and I/O amplification during congested object updates.

This change minimally refactors the state machine to ensure trim_lsn() is
strictly bound to the intended journal_trim_interval, while force_fsync
only triggers the necessary fsync_buffer().
changwei.ye requested review from vitalif 2026-09-14 13:16:54 +03:00
vitalif approved these changes 2026-09-24 11:08:05 +03:00
vitalif merged commit 6d1b9165a2 into master 2026-09-24 11:08:15 +03:00
Sign in to join this conversation.
Reviewers
No Reviewers
vitalif
Labels
No items
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
vitalif
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vitalif/vitastor#87
No description provided.
Delete Branch "changwei.ye/vitastor:fix-superblock-io-amplification"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?