7da8f80758
Summary: I want to make EdenMount robust if mounting and unmounting are requested concurrently. This will make it safer to call EdenMount::destroy in different situations. Take a step toward that goal by making EdenMount::unmount idempotent; calling EdenMount::unmount multiple times should return the same future. Changed behaviors: * If EdenMount::unmount is called multiple times, EdenMount::fuseMount is called at most once, and each call to EdenMount::unmount waits for the EdenMount::fuseMount call to finish. * **Old behavior**: One of the calls to unmount succeeds, and the remaining calls to unmount fail with an exception from PrivHelper. Unchanged behaviors: * If EdenMount::unmount was ever called, EdenMount::startFuse fails with EdenMountCancelled. * If EdenMount::unmount was ever called, EdenMount::takeoverFuse fails with EdenMountCancelled. * If EdenMount::startFuse is in progress, EdenMount::unmount causes the concurrent startFuse call to fail with FuseDeviceUnmountedDuringInitialization. * If EdenMount::startFuse -> PrivHelper::fuseMount is in progress, EdenMount::unmount waits for fuseMount to finish before calling PrivHelper::fuseUnmount. * If EdenMount::startFuse -> PrivHelper::fuseMount is complete, EdenMount::unmount calls PrivHelper::fuseUnmount immediately. * If EdenMount::takeoverFuse is in progress, EdenMount::unmount does not cause EdenMount::takeoverFuse to fail. * If EdenMount::takeoverFuse was called, EdenMount::unmount calls PrivHelper::fuseUnmount immediately. * If neither EdenMount::startFuse nor EdenMount::takeoverFuse was never called, EdenMount::unmount succeeds and does not call PrivHelper::fuseUnmount. Reviewed By: simpkins Differential Revision: D14398507 fbshipit-source-id: 1da5424abc47341e4db3da1c50d425711e177366 |
||
---|---|---|
CMake | ||
common | ||
eden | ||
.gitignore | ||
CMakeLists.txt | ||
CONTRIBUTING.md | ||
getdeps.py | ||
LICENSE | ||
make-client.py | ||
PATENTS | ||
README.md |
EdenFS is a FUSE virtual filesystem for source control repositories.
EdenFS speeds up operations in large repositories by only populating working
directory files on demand, as they are accessed. This makes operations like
checkout
much faster, in exchange for a small performance hit when first
accessing new files. This is quite beneficial in large repositories where
developers often only work with a small subset of the repository at a time.
EdenFS has similar performance advantages to using sparse checkouts, but a much better user experience. Unlike with sparse checkouts, EdenFS does not require manually curating the list of files to check out, and users can transparently access any file without needing to update the profile.
EdenFS also keeps track of which files have been modified, allowing very
efficient status
queries that do not need to scan the working directory.
The filesystem monitoring tool Watchman
also integrates with EdenFS, allowing it to more efficiently track updates to
the filesystem.
Building EdenFS
EdenFS currently only builds on Linux. We have primarily tested building it on Ubuntu 18.04.
TL;DR
[eden]$ ./getdeps.py --system-deps
[eden]$ mkdir _build && cd _build
[eden/_build]$ cmake ..
[eden/_build]$ make
Dependencies
EdenFS depends on several other third-party projects. Some of these are commonly available as part of most Linux distributions, while others need to be downloaded and built from GitHub.
The getdeps.py
script can be used to help download and build EdenFS's
dependencies.
Operating System Dependencies
Running getdeps.py
with --system-deps
will make it install third-party
dependencies available from your operating system's package management system.
Without this argument it assumes you already have correct OS dependencies
installed, and it only updates and builds dependencies that must be compiled
from source.
GitHub Dependencies
By default getdeps.py
will check out third-party dependencies into the
eden/external/
directory, then build and install them into
eden/external/install/
If repositories for some of the dependencies are already present in
eden/external/
getdeps.py
does not automatically fetch the latest upstream
changes from GitHub. You can explicitly run ./getdeps.py --update
if you
want it to fetch the latest updates for each dependency and rebuild them from
scratch.