Skip to content

Linux 6.17: fuse: add tracepoints for i_size changes, writeback ranges and READ replies - #268

Merged
hbirth merged 1 commit into
redfs-ubuntu-hwe-6.17.0-16.16-24.04.1from
red-51747-fuse-tracepoints-6.17
Oct 16, 2026
Merged

hbirth merged 1 commit into
redfs-ubuntu-hwe-6.17.0-16.16-24.04.1from
red-51747-fuse-tracepoints-6.17

Conversation

@cryptosven76

Copy link
Copy Markdown

Diagnostics only, no behaviour change. Tracepoints that would have made RED-51747 (write-back lost update on a page shared by two writers) visible straight from a trace, instead of reconstructed from DLM grant ordering. Related fixes: #264 (writeback clamp) and #266 (READ reply extends i_size).

Why

Under DLM with the writeback cache, i_size is only this node's view. Whether iomap writeback treats bytes as past EOF, zeroing them and possibly sending them, depends on what i_size was at that moment. In RED-51747 the decisive facts were the lower writer's i_size at writeback, iomap's end_pos, and that a READ had returned bytes past the local EOF. None of these is recorded today.

Tracepoints (TRACE_SYSTEM fuse)

Event Fields Call sites
fuse_isize_change nodeid, old → new i_size, reason (write_claim, write_retract, attr) the shared-lock extension claim and its retraction in fuse_cache_write_iter(); fuse_change_attributes_i() when it applies a different server size
fuse_writeback_range nodeid, pos, len, bytes sent, end_pos, current i_size fuse_iomap_writeback_range()
fuse_readfolio_reply nodeid, pos, length asked, bytes returned (or error), i_size fuse_do_readfolio()

The RED-51747 race then shows up as a fuse_writeback_range with end_pos below i_size and the full block sent, after a fuse_readfolio_reply that returned bytes past the local EOF. The send field equals len on this base; with #264 it shows the clamped length (a one-argument change at the call site once both are in).

Enable with echo 1 > /sys/kernel/tracing/events/fuse/enable (or per event). The events cost nothing when disabled; all call sites are in paths that already take fi->lock or do a server round trip.

Testing

Compile-tested only: built as the redfs DKMS module (same tree, renamed) against Ubuntu 6.17.0-42 with no warnings. The events have not been exercised at runtime yet.

🤖 Generated with Claude Code

…eplies

Under DLM with the writeback cache, i_size is only this node's view of
the file, and whether writeback treats bytes as past EOF depends on
what i_size was at that exact moment. When RED-51747 lost another
node's bytes to zeroes, the local i_size at writeback had to be
reconstructed from the order of DLM grants, because nothing records it.

Add three tracepoints:

  fuse_isize_change      every i_size change and why: the cached-write
                         extension claim, its retraction, or a size
                         taken from an attribute reply
  fuse_writeback_range   each writeback chunk with pos, len, bytes sent,
                         iomap's end_pos and the current i_size
  fuse_readfolio_reply   each fuse_do_readfolio() READ with the length
                         asked, the bytes returned and i_size

With these, the RED-51747 race shows up directly as a writeback chunk
whose end_pos is below i_size while its whole block is sent, preceded
by a READ reply that returned bytes past the local EOF.

Signed-off-by: Sven Oehme <soehme@ddn.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@hbirth
hbirth force-pushed the red-51747-fuse-tracepoints-6.17 branch from c54f263 to 17c0972 Compare October 16, 2026 09:03
@hbirth
hbirth merged commit f7cb6f4 into redfs-ubuntu-hwe-6.17.0-16.16-24.04.1 Oct 16, 2026
2 checks passed
@cryptosven76

Copy link
Copy Markdown
Author

Post-merge check on tyan-h3-u24: the deployed redfs.ko (DKMS red-client-fs-dkms 20261016.092513) registers all three events as redfs/redfs_isize_change, redfs/redfs_writeback_range and redfs/redfs_readfolio_reply under /sys/kernel/tracing/events. I have not enabled them yet, because a 3-hour RED-51747 verification run is in progress on that host.

🤖 Generated with Claude Code

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants