Bad case

[gaodq]

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main() {
  int fd = open("/jfs/testdata", O_RDWR);
  if (fd < 0) {
    printf("open file failed\n");
    exit(1);
  }
  const char* data = "helloworld\n";
  char buffer[1024];
  for (int i = 0; i < 1000000; i++) {
    int ret = read(fd, buffer, 1024);
    if (ret < 0 ) {
      printf("read file failed\n");
      exit(1);
    }
    off_t off = lseek(fd, -1, SEEK_CUR);
    int n = write(fd, data, strlen(data));
    lseek(fd, n + off, SEEK_SET);
  }
  close(fd);
}

最近测试中发现的一个问题，我发现 geopandas 的 to_file 函数写到 juicefs 特别慢，strace 后发现是这样的调用模式，写了这个
case 能复现问题，看现象是不停的覆盖之前的 chunk 导致生成新的 chunk 上传到 s3，请问这个现在有什么解决方法吗，有相关的缓存选项吗

s3里的object
  | 292_0_11 | - | 2021年6月24日 pm6:02:37 CST | 11.0B | 标准
  | 293_0_11 | - | 2021年6月24日 pm6:02:37 CST | 11.0B | 标准
  | 294_0_11 | - | 2021年6月24日 pm6:02:37 CST | 11.0B | 标准
  | 295_0_11 | - | 2021年6月24日 pm6:02:37 CST | 11.0B | 标准
  | 296_0_11 | - | 2021年6月24日 pm6:02:37 CST | 11.0B | 标准
  | 297_0_11 | - | 2021年6月24日 pm6:02:37 CST | 11.0B | 标准

> JuiceFS Profiling                Refresh: 2 seconds  2021-06-24T10:24:45

Operation           Count     Average(us)          Total(us)     Percent(%)
read                   70           31091            2176377          108.8
getattr                70             785              54984            2.7
write                  70              25               1730            0.1

[xiaogaozi]

There's a document about cache management: https://github.com/juicedata/juicefs/blob/main/docs/en/cache_management.md, please refer to it first.

[davies]

@gaodq 在这种 读写混合的情况下，JuiceFS 确实性能还比较差，因为目前的数据读写路径是独立的，每次读都会把内存中的数据 flush，导致读很慢。这种情况下需要启用内核FUSE模块的 writeback 功能（-o writeback_cache)，启用之后，上面的测试代码可以再 2 秒钟内完成，否则一直跑不完。

这个功能在商业版里已经支持，后续会给社区版也加上。

[davies]

the PR is ready: #576