mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 05:16:00 +03:00
[GH-ISSUE #2735] Negative stat cache not hit #1282
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1282
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Originally created by @francoisfreitag on GitHub (Oct 3, 2025).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2735
Additional Information
Version of s3fs being used (
s3fs --version)Commit:
37e593aeb0Version of fuse being used (
pkg-config --modversion fuse,rpm -qi fuseordpkg -s fuse)2.9.9-13.amzn2023.0.2
Provider (
AWS,OVH,Hetzner,iDrive E2, ...)AWS
Kernel information (
uname -r)6.1.134-152.225.amzn2023.x86_64
GNU/Linux Distribution, if applicable (
cat /etc/os-release)How to run s3fs, if applicable
[x] command line
s3fs syslog messages (
grep s3fs /var/log/syslog,journalctl | grep s3fs, ors3fs outputs)Details about issue
The negative cache entries are not reused on successive calls for a directory that does not exist.
I see the log “add negative cache entry” for my path (here
/user/.config), however the line “Hit negative stat cache” for this path always says[hit count=1], despite the repeated calls happening within hundreds of milliseconds and the expiry being set to 60 seconds.Not using this cache causes many extraneous HEAD requests (about 220 in my case), leading to significant performance loss (connecting to the chrooted SFTP environment takes about 20s, whereas it usually takes about 2s).
In case it helps, here’s the directory structure mounted from the S3FS-fuse we’re chrooting into:
@francoisfreitag commented on GitHub (Oct 3, 2025):
It might be related to
60fb557f14.The following patch fixes the issue for me:
cc @ggtakec, as you recently changed these files.
@ggtakec commented on GitHub (Oct 4, 2025):
@francoisfreitag Thanks for reporting it, I'll check what the problem is and how to fix it.
@ggtakec commented on GitHub (Oct 4, 2025):
@francoisfreitag
I've confirmed this bug, and your fixed code.
Your fix is mostly fine(although you need to slightly change how you pass the pmeta parameter).
I've created a PR #2736, so I'd appreciate it if you could take a look.
@francoisfreitag commented on GitHub (Oct 4, 2025):
I checked out your branch and confirm we’re back to the usual number of HEAD requests and performance. Thank you for fixing so quickly! 🌟