Summary: this is largely just markdownified comments from `eden/fs/utils/PathFuncs.h`. I've been a bit confused on the differences lately and how they interact, so I read through that file and thought a markdown file would be helpful for future reference, since the file is reaching 2000 lines.
Reviewed By: fanzeyi
Differential Revision: D19434132
fbshipit-source-id: 0ec5551e9da0a3202fcc3efff52f9f6f48f99db4
Summary: This is some documentation I've taken while studying the `Takeover.*` classes. It could be helpful to live in this folder for future reference. If I missed anything or misrepresented anything, please let me know! I plan to keep this updated as changes are made to files in this folder.
Reviewed By: simpkins
Differential Revision: D18868291
fbshipit-source-id: 8fc65dd3dd6f1b5bcc344b5f4c2b5b9ceb11ed17
Summary:
I was thinking about teaching EdenFS' `globFiles` to follow symlinks. To help me think, I documented my understanding of how EdenFS currently handles glob patterns. Publish my notes, even if I decide to not change `globFiles`' behavior.
This document isn't meant to be thorough, so many definitions and nuances are omitted.
Reviewed By: simpkins
Differential Revision: D14288417
fbshipit-source-id: e78749e114224926c2673868854d068672e38cef
Summary:
Describe the various caches in Eden and the decisions made while
shaping them.
Reviewed By: wez, strager
Differential Revision: D13149018
fbshipit-source-id: b7f25a3a25ec7ab3ff364fb0c4f4e755acec9a4e
Summary: Store tree and file timestamps in the InodeTable so they persist across runs.
Reviewed By: simpkins
Differential Revision: D6891479
fbshipit-source-id: 1c9e6266375aceeaf293a81e73cf7f5334dbc32d
Summary:
Every day I read this document and notice more of the awkward bits. :)
(Note: this ignores all push blocking failures!)
Reviewed By: pkaush
Differential Revision: D7602548
fbshipit-source-id: 71e30de869d97411e8fb86de0701ca7890942ddf
Summary:
Add a document that begins to sketch out the various transitions that
our inode data structures make so we can reason about their
correctness
Reviewed By: simpkins
Differential Revision: D7434693
fbshipit-source-id: 5478c108c338ccdadc22e864b077195c8be7d1b7
Summary:
For new folks and myself, here's a bit of prose that describes our
threading strategy.
Reviewed By: simpkins
Differential Revision: D6513572
fbshipit-source-id: a48e0152692aa63540f0be27f943fd6f29bb5fb2
Summary:
Update eden to log via the new folly logging APIs rather than with glog.
This adds a new --logging flag that takes a logging configuration string.
By default we set the log level to INFO for all eden logs, and WARNING for
everything else. (I suspect we may eventually want to run with some
high-priority debug logs enabled for some or all of eden, but this seems like a
reasonable default to start with.)
Reviewed By: wez
Differential Revision: D5290783
fbshipit-source-id: 14183489c48c96613e2aca0f513bfa82fd9798c7
Summary:
This is the initial code for implementing checkout.
This isn't quite 100% implemented yet, but I think it's worth checking in this
code as-is, and getting the remaining functionality done in separate diffs.
In particular, a few operations aren't implemented:
- Removing a directory that was deleted in the new revision
- Replacing a directory that was replaced with a file or symlink in the new
revision
- When doing a forced update, replacing a file or directory that did not exist
in the old revision, but that was created locally in the working directory,
and also exists in the new revision.
Reviewed By: wez
Differential Revision: D4538516
fbshipit-source-id: 5bb4889b02f23ab2048fcae2c8b7614340181aa6
Summary:
This updates the TreeInode::rename() code to handle concurrency better.
In particular:
- The code now ensures that both the source inode being renamed and destination
inode (if it exists) are loaded. This simplifies issues when an inode is
being loaded at the same time a rename is in progress. This ensures that any
pending load is processed before the rename takes place. (All promises for
the load might not be fulfilled before the rename completes, but the relevant
TreeInode and InodeMap data structures are updated before the rename occurs.)
This does mean that the rename code potentially might have to retry several
times if the inode it began loading is no longer the affected source or
destination or child once the load completes. However, this seems like a
reasonable trade-off, compared to dealing with the complications that would
arise with the load code having to handle renames occuring before load
completion.
- The code now implements proper lock ordering, to avoid acquiring locks in
conflicting orders that might cause deadlock with other threads also trying
to acquire the same locks. The InodeLocks.md document has been updated to
clarify the TreeInode lock ordering requirements.
Reviewed By: wez
Differential Revision: D4493526
fbshipit-source-id: 627393fafad90eb551aea62be7762d59ed043abe
Summary:
This describes the behavior around Inode ownership, loading and unloading, as
well as the synchronization around these events.
The InodeMap and InodePtr diffs implementing this behavior are still in flight.
Reviewed By: bolinfest
Differential Revision: D4356591
fbshipit-source-id: 298ba2c6aa98feba8b90f858e5633ca793276a1e
Summary:
Add a document describing the various inode related locks and the order that
they may be acquired.
Reviewed By: bolinfest
Differential Revision: D4356023
fbshipit-source-id: 44d4ade984f6cb49bb5f09deeeef0fd5439f129c
Summary: Restructure the current logic used for loading the config data into a ClientConfig object. Rather than having loadFromClientDirectory iterate through all the config files and parse them to find the necessary information, abstract that logic out into a new method that compiles all of the relevant data so that all loadFromClientDirectory has to do is pull out the needed information. Since this change separates the two steps, this will make it easier to move the first step of compiling config information outside of ClientConfig - the goal here is to have the eden server load all of the config data at start up and cache it in memory so that it doesn't need to be done every time a ClientConfig object is created, and this change is an intermediate step.
Reviewed By: simpkins
Differential Revision: D3580757
fbshipit-source-id: c340a0fe715856066a554238249574f8177bc4d7
