mirror of
https://github.com/facebook/sapling.git
synced 2024-10-10 08:47:12 +03:00
07df8faf5e
Summary: As opposed to FUSE, ProjectedFS sends notifications for file/directory creation after the fact, and for directory that means these will be visible on disk before EdenFS may be aware of it. While EdenFS usually process it quickly, a heavily multi-threaded application that tries to concurrently create a directory hierarchy may end up sending notifications to EdenFS in a somewhat out of order fashion. Since this should be a very rare occurence, we make this a very slow path by being optimistic and calling `getInode` first, and then only if that fails, we aggressively create all the parent directories. During a buck build of ~1k jobs, this happened only 3 times. If we fully think this through, this change doesn't fully fix the race, as a similar race can now happen when a create and remove/rename operations are concurrent. However, a client performing these operations concurrently is either aware that this is racy and should handle these properly, or is most likely buggy. Both of these should significantly reduce the likelyhod of this happening, thus, I'm leaving this unfixed for now. To better understand how frequently this happens, I've added a stat counter. For now, these aren't published to ODS, but this will be tackled later. Reviewed By: wez Differential Revision: D22783484 fbshipit-source-id: ea3aafc2f77b65d3967f697f68114921d5909137 |
||
|---|---|---|
| .. | ||
| fs | ||
| integration | ||
| locale | ||
| mononoke | ||
| scm | ||
| scripts | ||
| test_support | ||
| test-data | ||
| win | ||
| .clang-format | ||
| .gitignore | ||
| Eden.project.toml | ||