Summary:
Currently we skip metadata when constructing data wirepacks.
We need copy metadata in the data packflies, because the client expects the base text to contain copy metadata since the delta base on the server also contains copy metadata.
It is also needed for future file nodes validation.
Differential Revision: D14851678
fbshipit-source-id: 1a3f79dc2565cdb864bee2400d331ae3a7c3751b
Summary: Allow users to configure which HTTP client backend to use for the Eden API via the `edenapi.backend` config option. Valid options are `curl` and `hyper`, with `curl` being the default.
Reviewed By: quark-zju
Differential Revision: D14657871
fbshipit-source-id: 7a9972d2380fbbd5ed62d1accae764dc03ca4c29
Summary:
In most cases, we won't have more packfiles than what is held in the LRU cache,
and therefore, building a set is unecessary. Testing for the length is a O(1)
operation and is therefore a quick test to verify if more packs needs to be
iterated on.
Reviewed By: quark-zju
Differential Revision: D14802940
fbshipit-source-id: 8b39befb27368d474ab71f3eeac2340d8183e70e
Summary:
When many packfiles are present, and searching for missing data, we will
iterate on the packs twice. We can avoid the second iteration by testing if new
packfiles were detected.
Reviewed By: quark-zju
Differential Revision: D14802942
fbshipit-source-id: 624d9a86e65395af3141ea10d42bcfb8ee18db83
Summary:
Building a set is a O(n) operation, and in the cases where refresh is called
often, it starts showing up in profiles. Instead of rebuilding it everytime, we
can simply update it when adding/removing packs.
Reviewed By: quark-zju
Differential Revision: D14802945
fbshipit-source-id: f8967d09d2d7d0cc0d7400b047a587d536315002
Summary:
The repo.ui.configbool was showing in profiles when running `hg log -p`. Since
its value won't change for the duration of the operation, let's cache it.
Reviewed By: quark-zju
Differential Revision: D14802941
fbshipit-source-id: c1a2a764cb4d4a1c0d45d5118bb1e892c10798a6
Summary:
One of the drawback of only using packfiles is the cost of the pathological
cases when one pack file is being downloaded per file. This can happen during a
`hg log -p`, or on Eden when running `cat` on lots of not materialized files.
In these cases, mercurial will become slower and slower as the command is
running.
This is due to mercurial having to search each individual packfile to find
whether some data exist locally, or it needs to be fetched from the network.
This search will iterate over each packfile linearly, and on a miss, a
directory scan will be performed to see if a new packfile is present.
Previous patches attempted to solve this by running a repack when the command
finishes, but in the case of `hg log -p`, or when Eden is requesting the
content of some file, the command could be running for a long time.
As a solution, let's repack while the command is running if we detect that too
many pack files are present.
Reviewed By: quark-zju
Differential Revision: D14740566
fbshipit-source-id: 95ba381bd99e5404e352f799e9053a6375abac0a
Summary:
Loosefiles are quite slow to repack, and this is significantly affecting
laptops as the repack can potentially run for hours when a large amount of
loosefiles are present.
One of the reason for that is that an incremental repack really isn't
incremental for loosefiles as all of them are repacked at the same time.
Instead let's repack only one of the top-level directory at a time.
Reviewed By: quark-zju
Differential Revision: D14690348
fbshipit-source-id: ffba49840302ae0d99e32db410647e83e213fe64
Summary: Previously the debug commands for the Eden API did not check whether HTTP data fetching was enabled before trying to access the client singleton, which would result in a crash if HTTP was disabled. This diff adds explicit checks so that the commands will abort instead of crashing.
Reviewed By: quark-zju
Differential Revision: D14692893
fbshipit-source-id: d36e241d8460dadb555a15c92aca9334ba00f34c
Summary:
With `remotefilelog.fetchpacks`, some pathological cases would end up creating
tons of packfiles and we would thus spend a significant amount of time in
refresh, scanning for new packfiles. Jeremy noted that for every refresh,
stat(2) would be ran on every file, even though only a handful of packfile
would be added.
Differential Revision: D14674093
fbshipit-source-id: df198d208e3f4e1d667e7bdd069a793984683282
Summary:
Now that repacks runs more often, it's easier to trigger a race between repack
deleting packfiles, and another mercurial process listing the packfiles and
trying to open them. If the packfiles are deleted after the directory listing,
all the packfiles will fail to be opened and were mis-reported as corrupted.
Reviewed By: quark-zju
Differential Revision: D14648308
fbshipit-source-id: c3b852f669e28db6f622bde217f339533e094223
Summary:
The extdiff extension uses archive on the workingctx to make snapshots
of certain files. Prefetching fails on this because it sees placeholder file
nodes. Let's just not prefetch in this case at all.
Differential Revision: D14609691
fbshipit-source-id: 2d06bf015a8b10afa16b3b0bcb266afb102d63b9
Summary:
Now that we have perftracing infra, let's trace a bunch of likely
problem spots.
Reviewed By: sfilipco
Differential Revision: D14426367
fbshipit-source-id: 354a241aa9ac5d75d34062a9838d581b4f46746f
Summary:
Most of the repacks are background repacks, and most of the complaints are
coming from laptops users. Thanks to the rust repack, most of time during
repack is now spent in repacking loosefiles. While repacking them is expensive,
testing whether data is in a loosefile and obtaining it is actually pretty
fast. Packfiles have the opposite issue, repacking them is fast, but finding
data in them may be expensive if a lot of them are present.
Based on this, it makes sense to repack packfiles more frequently than
loosefiles. At first, the newly added option will be used to turn-off loosefile
repack for laptop users. A less frequent loosefile repack will be implemented
in a later patch.
Reviewed By: DurhamG
Differential Revision: D14586986
fbshipit-source-id: 5bc5c839cf8d2d78bcc4ffa016bbe3cf1b2ef3f7
Summary: Added new metrics to log loose files size and number during repack. We need it to understand how much better the pack files work in terms of disc and memory usage.
Reviewed By: markbt
Differential Revision: D14544811
fbshipit-source-id: 5a4d894bd5a3358c7e0f93ecc9db5e9f2c2f2372
Summary: Log data about round-trip count, and object count for files, trees, and SSH calls.
Differential Revision: D14515776
fbshipit-source-id: cce416fd7dccdad3c73a9f1751a04ddac0d2c507
Summary:
Not every command requires a valid repo, but when one is used, it is always
properly closed. Hence, let's simply wrap the repo.close method instead of
wrapping around the runcommand function.
Reviewed By: kulshrax
Differential Revision: D14531515
fbshipit-source-id: bcdbe6530c94041c1185b18570846ba609b5f605
Summary:
Reading a line over a pipe involves reading every character of the line
individually. This is extremely inefficient and slow, which cause prefetch to
be overly slow when most of the data isn't in memcache.
Using buffered reads tries to read 4096 bytes at a time, drastically reducing
the cost of reading a missing path/node pair from memcache.
Reviewed By: ikostia
Differential Revision: D14507063
fbshipit-source-id: e0910d7a303e15fe2d3c61fe2739e6c13370058f
Summary: D14387734 added 2 new arguments to the `httprequestpacks` function, but didn't update the callsite to pass those arguments. This diff fixes the problem.
Differential Revision: D14468592
fbshipit-source-id: 7e573838916067fc2cc12204ea1da460eb3955c8
Summary:
Currently archive is almost useless because it fetches each file
one-by-one. Let's add prefetching.
Differential Revision: D14460880
fbshipit-source-id: 1f06e1ac9d03aae3ab27d3064f9fe6141051be06
Summary:
Now that hg_memcache_client will voluntarily exit when hg terminates, we no
longer need to wait for hg_memcache_client to finish before exiting hg.
Reviewed By: DurhamG
Differential Revision: D14396510
fbshipit-source-id: 7e73d9b70d481e58a0c47cd0f408580e6d548fd9
Summary:
Operations like `hg log -p` will inherently cause many requests to
hg_memcache_client. This will force many small packfiles to be created which
will significantly slow down future invocation of hg.
Now that `hg repack --incremental --packsonly` is fast, we can afford to run it
when mercurial exit after a prefetch operation was run.
Differential Revision: D14387735
fbshipit-source-id: 45f89f1120458c8b2471a1c55cafb6bc87263dd0
Summary:
When using packfiles, history and data are in different files, and thus it's
possible to only fetch one.
For now, besides the requests coming from contentstore and metadatastore, both
will be fetched, as the code hasn't been audited to know whether we only want
history or data.
Differential Revision: D14387734
fbshipit-source-id: 6aafd477ff486b9316458ce0e80636152db45b89
Summary:
Corrupted packfiles, or background removal of them could cause repack to fail,
let's simply ignore these transient errors and continue repacking.
Reviewed By: DurhamG
Differential Revision: D14373901
fbshipit-source-id: afe88e89a3bd0d010459975abecb2fef7f8dff6f
Summary:
If an infinitepush bundle contains flat manifests and is served from a
treemanifest repository, it can potentially fail to send all the needed data to
the client.
Understanding the bug requires two bits of context:
1. When sending commits from a tree server to a tree client, we generally don't
send any trees because they can be fetched by the client ondemand later. The one
exception to this is for infinitepush bundles, where the trees inside the bundle
cannot be served ondemand, and therefore must be served at pull time. To do this
we check if a given manifest node exists in the repositories permanent storage,
and if it doesn't, we assume it came from an infinitepush bundle and serve it
with the pull.
2. When we lookup a manifest and fail to find a tree, our last resort is the
ondemandstore which knows how to convert a flat manifest into a tree manifest.
On the server, this is responsible for converting each of the flat bundle's
manifests into treemanifests before we serve the bundle to the client. As part
of converting the flat manifests into treemanifests, it writes the new tree
data into a pack file.
The bug is then, when serving a stack of commits, if we try to package up the
top tree first (i.e. the most recent tree), we end up converting the entire
stack from flat into trees, which inserts the bottom most trees into the
temporary pack file. Because they exist in the temporary pack file, when we
later check if they are part of the repositories store we end up finding them,
which causes us to treat them as not-infinitepush-trees which means we don't
serve them to the client.
The fix is to change the infinitepush tree-serving code to not consider the
mutable packs when checking if it should send trees.
Reviewed By: mitrandir77
Differential Revision: D14403925
fbshipit-source-id: 38043dfc49df5ff9ea2fae1d3cac341c4936509c
Summary:
When searching for data, mercurial will search the datastores by first looking
into the local cache, then try to find the data over the network. When
remotefilelog.fetchpacks is enabled, all the data fetched over the network will
be stored into packfiles, but those fetches are done via the loose-files remote
datastore. Due to this, even if memcache successfully find the requested data,
the datastore won't find it, due to it expecting loosefiles.
Fixing this simply requires the fetches to be done via a packfile store when
remotefilelog.fetchpacks is enabled.
Reviewed By: DurhamG
Differential Revision: D14216815
fbshipit-source-id: ed97c64651a733b36e0f2b4e209ce8ccdbb7911e
Summary:
When using memcache in its packfile mode, the key no longer contains the name
of the repo, and therefore, memcache will store the downloaded packfiles under
/var/cache/hgcache instead of /var/cache/hgcache/fbsource/packs.
Reviewed By: quark-zju
Differential Revision: D14217056
fbshipit-source-id: f78ce1021985dbb71a1db21d8821e8b8fcda8179
Summary: Apparently we need to add newlines between config items in the docstring to ensure that it gets formatted correctly in the help output. A similar change was made upstream: https://www.mercurial-scm.org/repo/hg/rev/040447dc3c62
Reviewed By: quark-zju, singhsrb
Differential Revision: D14267738
fbshipit-source-id: c61f67f2c119fd9d71326eb42c2a4aa2106573da
Summary: Allow file data/history packs to be fetched via HTTP when the Eden API is enabled.
Reviewed By: quark-zju
Differential Revision: D14257368
fbshipit-source-id: 8b6823a57a6fdef546a596df20387b3fc1ccdd4a
Summary: This diff adds a new `hg debuggethistory` command that takes filenode/path pairs from stdin, fetches the history of the files from the API server, and writes the results to a historypack in the hg cache.
Reviewed By: quark-zju
Differential Revision: D14248082
fbshipit-source-id: 8014a758abd3a578ea213d8d3177812629b2fd51
Summary: The Eden API client in Mercurial should be a singleton. This diff assigns the client to `repo.edenapi` so that it is accessible throughout the code.
Reviewed By: quark-zju
Differential Revision: D14233314
fbshipit-source-id: 8e0ed22c32611e8f6e7d4461c3e31870d47a0e95
Summary: Add a `--long` option, similar to the one avaiable on `hg debugdatapack`, which prints full node hashes.
Differential Revision: D14256168
fbshipit-source-id: 342932aa4dd96197daf6bbba7b5bc8623ebbf9bd
Summary:
When the pack directory is missing, os.listdir will throw an OSError. Instead
of failing repack, let's just ignore the error.
Reviewed By: singhsrb
Differential Revision: D14234830
fbshipit-source-id: 14e683b7d850ab316d9821031e91a19e5f2f4c1e
Summary:
Instead of falling back to python, we should just skip the current repack. The
python code already does this, but the rust one will report the error to the
user (and scuba).
Reviewed By: singhsrb
Differential Revision: D14234831
fbshipit-source-id: d285499ae85205d6ccee3c22eb50352d77673488
Summary:
When pushing an empty commit, the server receives a pack part with no
data, which ends up not producing any pack files. Some newly added logic tries
to access the pack paths, which then crash.
Let's fix it so we get None for the paths in this situation, and update the only
consumers of those paths to handle the None case.
Reviewed By: quark-zju
Differential Revision: D14237452
fbshipit-source-id: 418bd30179fdb76b9de3bc2c2509079502edfef8
Summary:
Treemanifest uses it's own fallbackpath for reads in all cases, but
particularly in the case of remotenames it should stay on the path that is
actively being used by the push. It is possible to have remotenames which are
mirrored and selected by query strings in the repo path. In this case it is
possible that the mirror is still out of date when reading back data from our
push. Ensure that when doing a push the remote server this is considered
'sticky' so that we read back from the remote we pushed to, rather then
determening the path ourselves.
To disable, please use:
treemanifest.stickypushpath=False
Reviewed By: DurhamG, markbt, quark-zju
Differential Revision: D14165444
fbshipit-source-id: 75a53ffab895d87a4c52814f7887145c134868b5
Summary:
During repack, the repacked files are deleted without any verification. Since
Adam saw some data loss, it's possible that somehow repack didn't fully repack
a packfile but it was deleted. Let's verify that the entire packfile was
repacked before deleting it.
Since repack is mostly a background operation, we don't have a way to notify
the user, but we can log the error to a scuba table to analyse further.
Reviewed By: DurhamG
Differential Revision: D14069766
fbshipit-source-id: 4358a87deeb9732eec1afdfb742e8d81db41cd87
Summary:
Removing files on Windows is hard. It can fail for many reasons, many of which
involves another process having the file opened in some way. One way to solve
this problem is that renaming the file isn't as restrictive as removing it.
Since hg repack will attempt removing any temporary files it will also try to
remove the packfiles that we failed to remove earlier.
Reviewed By: DurhamG
Differential Revision: D14030445
fbshipit-source-id: 1f3799e021c2e0451943a1d5bd4cd25ed608ffb6
Summary:
Preloading all the pack files on initialization ties the lifetime of the
packfiles to the repo. For normal operations, this is fine, as packfiles are
mostly read. During a repack however, we need to be able to remove them, and
while having an open file handle allows deletion on unix OSes, it prevents it
on Windows.
The Rust repack now succeeds on Windows.
Reviewed By: DurhamG
Differential Revision: D14013786
fbshipit-source-id: 99279d4af67a0dfe8679159e9409186f56a09296
Summary: We were reading the `edenapi.url` config item without explicitly setting it up with the `configitem()` function. Not sure what negative impact this would have, but it's probably a good idea to have the explicit call in place.
Reviewed By: quark-zju
Differential Revision: D14075080
fbshipit-source-id: bb4e25de273341768f850f1d5aab6ac21e7f2fc5
Summary: Now that the `edenapi` module in bindings is always available for all platforms, we no longer need a try block around the import.
Reviewed By: quark-zju
Differential Revision: D14075082
fbshipit-source-id: e3f45e67ef4572e58f85875af12390ea5d697d43
Summary: Move the edenapi Python bindings into the common `bindings` crate.
Reviewed By: quark-zju
Differential Revision: D13963179
fbshipit-source-id: 76dead82af992615a9e452ee6fbb9f66639c822c
Summary:
The refresh function is intended to load on-disk packfiles that aren't yet
present in the cache, but it had several issues that resulted in unexpected
behavior. Mainly, the new files would be added in the wrong order in the cache,
and runonpacks would not update the last used packs.
Differential Revision: D14013785
fbshipit-source-id: da4151b859441f0ba51863f3907852922c255f82
Summary:
Previously, the logic for chosing between the rust repack, and the python one
was deeply integrated with the python repack. This resulted in work being
performed unnecessarily.
The drawbacks of this method is that in the case of fallback to Python, the
repacklock will be dropped and re-obtained, as well as the prerepack hook will
be ran twice. Since the python code will soon be entirely replaced this is
probably not important.
Differential Revision: D14013790
fbshipit-source-id: 7c754db3fb984cc9e6b7df1a4e32b72fa4a1531b
Summary: Most of the code is identical between these 2 functions, so let's merge them.
Differential Revision: D14013787
fbshipit-source-id: f0469e05fcf723db02d9f4c28097e61f958284a5
Summary:
To connect to the memcache client it used a path from a loose files data store (`remotefilelogcontentstore._path`), which is a path to the hg cache, but pack files store doesn't have the same field.
I replaced the path with cache path from shallowutil.
Reviewed By: singhsrb, liubov-dmitrieva
Differential Revision: D14020122
fbshipit-source-id: 29bc8a01fc42d43eddc6ae67cf4e41fc552e117c
Summary:
The super python builtin expects a type as an argument, while a string was
passed, this was causing trouble for some users.
Reviewed By: DurhamG
Differential Revision: D14012716
fbshipit-source-id: 6714eb20745428818721ec3df85588a7b4c7ebb7
Summary:
If the history portion of a loose file was corrupt, users would often
get errors like "ValueError: substring not found" when trying to split on the
null separators. Let's catch that and handle it where appropriate. For cache
stores, we move it out of the way and return a KeyError, so the union store will
move on to try to fetch it from the server again. For local stores, we return a
ValueError and surface it to the user since their local data may be corrupt.
Reviewed By: quark-zju
Differential Revision: D13976499
fbshipit-source-id: 39e63f19fc752ca0179fbc5b0908a28d46de3a3a
Summary:
simplecache can be configured with memcache backend
this will potentially save us a lot of disk space and allow us to have a shared cache between hg hosts.
getting rid of the caches on disks will save 966GB of disk space per machine.
P60876105
Reviewed By: quark-zju
Differential Revision: D13950137
fbshipit-source-id: 015e971f1bfed334edb4fe2381c2c6336b84b161
