Object files of non-existing files may leak when we committing it to meta

[daimashusheng]

If we fail to submit the meta with an error code ENOENT, it means that the file may have been deleted at another mount point, so we should delete the uploaded object files to prevent leakage.

What happened:

When I'm writing a file at a mount point and deleting it at the same time at another one, committing meta could fail with an error code ENOENT, because the file has been deleted at another mount point, so we should delete the uploaded object files to prevent them leaked.

2024/09/03 14:28:25.191141 juicefs[398] <DEBUG>: PUT chunks/0/16/16385_0_6 (req_id: "", err: <nil>, cost: 675.04µs) [cached_store.go:673]
2024/09/03 14:28:55.192638 juicefs[398] <ERROR>: write inode:3074 indx:0  no such file or directory [writer.go:212]

but the obj file still exists

[root@localhost jfs_test]# stat /var/jfs/objtest/chunks/0/16/16385_0_6 
  File: ‘/var/jfs/objtest/chunks/0/16/16385_0_6’
  Size: 6               Blocks: 8          IO Block: 4096   regular file
Device: 803h/2051d      Inode: 107097350   Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:var_t:s0
Access: 2024-09-03 14:28:25.189048616 +0800
Modify: 2024-09-03 14:28:25.190048623 +0800
Change: 2024-09-03 14:28:25.190048623 +0800
 Birth: -

Environment:

• JuiceFS version: juicefs version 1.3.0-dev+2024-09-02.44eebbc
• Cloud provider or hardware configuration running JuiceFS:
• OS (e.g cat /etc/os-release): centos7
• Kernel (e.g. uname -a): 3.10.0-1160.105.1.el7.x86_64
• Object storage (cloud provider and region, or self maintained): local file system
• Metadata engine info (version, cloud provider managed or self maintained): sqlite
• Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage):
• Others: