mirror of
https://github.com/facebook/sapling.git
synced 2024-10-07 15:27:13 +03:00
d780d3813a
Summary: We noticed that some operations were surprisingly slow and the hypothesis was that caching in the kext wasn't working well. I traced into this with a simple repeated `realpath` of the same file while running the server with debug logging turned up. That showed that we were getting two requests from the kernel for each inode in the path resolution for each invocation of the realpath tool. I switched to looking at the kext code and found this section to be a potential issue: https://github.com/osxfuse/kext/blob/support/osxfuse-3/osxfuse/fuse_internal.h#L711 ``` /* XXX: truncation; user space sends us a 64-bit tv_sec */ \ VTOFUD(vp)->attr_valid.tv_sec = (time_t)struct_name ## _get_attr_valid(fuse_out); \ VTOFUD(vp)->attr_valid.tv_nsec = struct_name ## _get_attr_valid_nsec(fuse_out); \ nanouptime(&uptsp_ ## __funct__); \ ``` Switching our default TTL to be the maximum possible value that fits in a signed 32-bit time_t cuts down on the requests from the kernel to a single lookup for the symlink: ``` V1105 15:56:28.900839 28132386 FuseChannel.cpp:1141] fuse request opcode=1 FUSE_LOOKUP unique=2 len=47 nodeid=14910747 uid=2048904527 gid=1876110778 pid=24546 V1105 15:56:28.900885 28132386 FuseChannel.cpp:1437] FUSE_LOOKUP parent=14910747 name=README V1105 15:56:28.901111 28143988 FuseChannel.cpp:421] sendRawReply: unique=2 header->len=160 wrote=160 ``` and no requests at all for a plain file in the repo. Reviewed By: simpkins Differential Revision: D18340767 fbshipit-source-id: caebf051a543c54f7a03852fd2e0abab68448ded |
||
|---|---|---|
| .. | ||
| fuse_tester | ||
| privhelper | ||
| test | ||
| BufVec.cpp | ||
| BufVec.h | ||
| CMakeLists.txt | ||
| DirList.cpp | ||
| DirList.h | ||
| Dispatcher.cpp | ||
| Dispatcher.h | ||
| FuseChannel.cpp | ||
| FuseChannel.h | ||
| FuseTypes.h | ||
| InodeNumber.cpp | ||
| InodeNumber.h | ||
| PollHandle.cpp | ||
| PollHandle.h | ||
| RequestData.cpp | ||
| RequestData.h | ||