ilixiaocui
ilixiaocui
All mount points on the same file system are either enableCto, or they do not guarantee consistency. fix by pr: https://github.com/opencurve/curve/pull/1771
Code still needs to be optimized
FuseOpRelease is asynchronously Solution: same as https://github.com/opencurve/curve/issues/1197 Let FuseOpFlush handle the logic in FuseOpRelease.
mountpoint2: I 2022-07-22T17:13:30.727069+0800 920487 client_s3_adaptor.cpp:108] write start offset:654, len:8, fsId:7, inodeId:9438087(拿到的inode offset是不对的) mountpoint1: m1: 606 622 638 654 m2: 614 630 646 **654(出错)** As can be seen from the above,...
Interface calls corresponding to open and close： ``` I 2022-07-28T10:14:00.800768+0800 1435874 fuse_client.cpp:776] FuseOpGetAttr ino = 1 I 2022-07-28T10:14:00.801374+0800 1451587 fuse_client.cpp:286] FuseOpLookup parent: 1, name: test62 I 2022-07-28T10:14:00.802011+0800 1453049 fuse_client.cpp:776] FuseOpGetAttr...
> By Analyzing the heap profiler, I found redundancy of memory, follows > > 1. when key is std::string, the Item and unordered_map key construct std::string twice > 2. when...
> I think we can close it. @ilixiaocui We also need a test result, how much the optimized memory saves compared to the case of 100w or more records.
> > > I think we can close it. @ilixiaocui > > > > > > We also need a test result, how much the optimized memory saves compared to...
> > > > > I think we can close it. @ilixiaocui > > > > > > > > > > > > We also need a test result,...
related: https://github.com/opencurve/curve/issues/1435