[GH-ISSUE #2189] Delay in updating file's modified timestamp on EBS #1116

New issue

Closed

opened 2026-03-04 01:51:31 +03:00 by kerem · 1 comment

kerem commented

2026-03-04 01:51:31 +03:00

Owner

Originally created by @nitishtw on GitHub (Jun 17, 2023).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2189

We have mounted an s3 bucket through s3fs onto an EC2 machine which is being used for an SFTP use-case. We have lately observed that if the same file is re-uploaded to s3 bucket then it takes around 5-10 mins time to reflect the updated modification time inside EC2 box.

Ex - If a file cost.csv is re-uploaded at 3:40 PM in s3 bucket then if I run ls -lah inside EC2 box; the mtime of file will not be modified for the first 5-10 mins; and it will not reflect 3:40 PM as mtime of the file.

Initially we had a hunch that it was happening due to s3 eventual consistency model; but we also have one AWS managed transfer family setup which also use s3 as backend; and we haven't seen any use-case or behaviour like this.

AWS support also confirmed that this might be an issue with s3fs and not with s3! Have we seen such issues in past or is it a known issue? and is there any suggested fix for this?

Originally created by @nitishtw on GitHub (Jun 17, 2023). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2189 We have mounted an s3 bucket through `s3fs` onto an EC2 machine which is being used for an SFTP use-case. We have lately observed that if the same file is re-uploaded to s3 bucket then it takes around 5-10 mins time to reflect the updated modification time inside EC2 box. Ex - If a file `cost.csv` is re-uploaded at 3:40 PM in s3 bucket then if I run `ls -lah` inside EC2 box; the mtime of file will not be modified for the first 5-10 mins; and it will not reflect 3:40 PM as mtime of the file. Initially we had a hunch that it was happening due to s3 eventual consistency model; but we also have one AWS managed transfer family setup which also use s3 as backend; and we haven't seen any use-case or behaviour like this. AWS support also confirmed that this might be an issue with s3fs and not with s3! Have we seen such issues in past or is it a known issue? and is there any suggested fix for this?

kerem closed this issue

2026-03-04 01:51:31 +03:00

kerem commented

2026-03-04 01:51:32 +03:00

Author

Owner

@gaul commented on GitHub (Jun 20, 2023):

s3fs caches stat entries for 900 seconds (15 minutes) by default. You can control this via -o stat_cache_expire

@gaul commented on GitHub (Jun 20, 2023): s3fs caches stat entries for 900 seconds (15 minutes) by default. You can control this via `-o stat_cache_expire`

kerem referenced this issue

2026-03-04 02:02:21 +03:00

[PR #1116] [MERGED] Do not heap allocate BodyData #1827