diff options
| author | Filipe Manana <fdmanana@suse.com> | 2026-07-14 15:40:09 +0100 |
|---|---|---|
| committer | David Sterba <dsterba@suse.com> | 2026-08-07 19:17:18 +0200 |
| commit | 4bdec1b14b1f0942de763215b4102bbdc090c752 (patch) | |
| tree | 567016f531b215e4972a391b0f3aef8d62374b17 /tools/perf/scripts/python/bin | |
| parent | 5093038fc21d9b0f8211c28b90c7566397ac88a3 (diff) | |
btrfs: remove log batch counter use for fsync
We have the log batch counter defined per root which is now useless after
the previous patch (titled: "btrfs: stop sleeping for one jiffy in non-ssd
mounts during log commit"). The counter is incremented early in the fsync
path, before and after flushing dellaloc and waiting for writeback, and
then the counter is read during the log sync path. The goal was to wait
for tasks that are about to join a log transaction, so that we could
reduce the amount of IO and log syncing (flush all log tree extent buffers
and write super blocks), but that mechanism does not work since if there
are currently no log writers, btrfs_sync_log() does not unlock the root's
log_mutex, so no new log writers can join the log transaction. Having
concurrent fsync tasks increasing the log_batch counter only makes us loop
unnecessarily in btrfs_sync_log() - that is always true since the previous
patch mentioned above and was true before that patch only when not using
the "-o ssd" mount option (which is activated by default if the filesystem
does not have rotational devices).
So remove the log batch counter. No performance changes were observed
after removing it.
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
