##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

changegroup: remove reordering control (BC)...
changegroup: remove reordering control (BC) This logic - including the experimental bundle.reorder option - was originally added in a8e3931e3fb5 in 2011 and then later ported to changegroup.py. The intent of this option and associated logic is to control the ordering of revisions in deltagroups in changegroups. At the time it was implemented, only changegroup version 1 existed and generaldelta revlogs were just coming into the world. Changegroup version 1 requires that deltas be made against the last revision sent over the wire. Used with generaldelta, this created an impedance mismatch of sorts and resulted in changegroup producers spending a lot of time recomputing deltas. Revision reordering was introduced so outgoing revisions would be sent in "generaldelta order" and producers would be able to reuse internal deltas from storage. Later on, we introduced changegroup version 2. It supported denoting which revision a delta was against. So we no longer needed to sort outgoing revisions to ensure optimal delta generation from the producer. So, subsequent changegroup versions disabled reordering. We also later made the changelog not store deltas by default. And we also made the changelog send out deltas in storage order. Why we do this for changelog, I'm not sure. Maybe we want to preserve revision order across clones? It doesn't really matter for this commit. Fast forward to 2018. We want to abstract storage backends. And having changegroup code require knowledge about how deltas are stored internally interferes with that goal. This commit removes reordering control from changegroup generation. After this commit, the reordering behavior is: * The changelog is always sent out in storage order (no behavior change). * Non-changelog generaldelta revlogs are reordered to always be in DAG topological order (previously, generaldelta revlogs would be emitted in storage order for version 2 and 3 changegroups). * Non-changelog non-generaldelta revlogs are sent in storage order (no behavior change). * There exists no config option to override behavior. The big difference here is that generaldelta revlogs now *always* have their revisions sorted in DAG order before going out over the wire. This behavior was previously only done for changegroup version 1. Version 2 and version 3 changegroups disabled reordering because the interchange format supported encoding arbitrary delta parents, so reordering wasn't strictly necessary. I can think of a few significant implications for this change. Because changegroup receivers will now see non-changelog revisions in DAG order instead of storage order, the internal storage order of manifests and files may differ substantially between producer and consumer. I don't think this matters that much, since the storage order of manifests and files is largely hidden from users. Only the storage order of changelog matters (because `hg log` shows the changelog in storage order). I don't think there should be any controversy here. The reordering of revisions has implications for changegroup producers. Previously, generaldelta revlogs would be emitted in storage order. And in the common case, the internally-stored delta could effectively be copied from disk into the deltagroup delta. This meant that emitting delta groups for generaldelta revlogs would be mostly linear read I/O. This is desirable for performance. With us now reordering generaldelta revlog revisions in DAG order, the read operations may use more random I/O instead of sequential I/O. This could result in performance loss. But with the prevalence of SSDs and fast random I/O, I'm not too worried. (Note: the optimal emission order for revlogs is actually delta encoding order. But the changegroup code wasn't doing that before or after this change. We could potentially implement that in a later commit.) Changegroups in DAG order will have implications for receivers. Previously, receiving storage order might mean seeing a number of interleaved branches. This would mean long delta chains, sparse I/O, and possibly more fulltext revisions instead of deltas, blowing up storage storage. (This is the same set of problems that sparse revlogs aims to address.) With the producer now sending revisions in DAG order, the receiver also stores revisions in DAG order. That means revisions for the same DAG branch are all grouped together. And this should yield better storage outcomes. In other words, sending the reordered changegroup allows the receiver to have better storage order and for the producer to not propagate its (possibly sub-optimal) internal storage order. On the mozilla-unified repository, this change influences bundle generation: $ hg bundle -t none-v2 -a before: time: real 355.680 secs (user 256.790+0.000 sys 16.820+0.000) after: time: real 382.950 secs (user 281.700+0.000 sys 17.690+0.000) before: 7,150,228,967 bytes (uncompressed) after: 7,041,556,273 bytes (uncompressed) before: 1,669,063,234 bytes (zstd l=3) after: 1,628,598,830 bytes (zstd l=3) $ hg unbundle before: time: real 511.910 secs (user 466.750+0.000 sys 32.680+0.000) after: time: real 487.790 secs (user 443.940+0.000 sys 30.840+0.000) 00manifest.d size: source: 274,924,292 bytes before: 304,741,626 bytes after: 245,252,087 bytes .hg/store total file size: source: 2,649,133,490 before: 2,680,888,130 after: 2,627,875,673 We see the bundle size drop. That's probably because if a revlog internally isn't storing a delta, it will choose to delta against the last emitted revision. And on repos with interleaved branches (like mozilla-unified), the previous revision could be an unrelated branch and therefore be a large delta. But with this patch, the previous revision is likely p1 or p2 and a delta should be small. We also see the manifest size drop by ~50 MB. It's worth noting that the manifest actually *increased* in size by ~25 MB in the old strategy and decreased ~25 MB from its source in the new strategy. Again, my explanation for this is that the DAG ordering in the changegroup is resulting in better grouping of revisions in the receiver, which results in more compact delta chains and higher storage efficiency. Unbundle time also dropped. I suspect this is due to the revlog having to work less to compute deltas since the incoming deltas are more optimal. i.e. the receiver spends less time resolving fulltext revisions as incoming deltas bounce around between DAG branches and delta chains. We also see bundle generation time increase. This is not desirable. However, the regression is only significant on the original repository: if we generate a bundle from the repository created from the new, always reordered bundles, we're close to baseline (if not at it with expected noise): $ hg bundle -t none-v2 -a before (original): time: real 355.680 secs (user 256.790+0.000 sys 16.820+0.000) after (original): time: real 382.950 secs (user 281.700+0.000 sys 17.690+0.000) after (new repo): time: real 362.280 secs (user 260.300+0.000 sys 17.700+0.000) This regression is a bit worrying because it will impact serving canonical repositories (that don't have optimal internal storage unless they are reordered - possibly as part of running `hg debugupgraderepo`). However, this regression will only be noticed by very large changegroups. And I'm guessing/hoping that any repository that large is using clonebundles to mitigate server load. Again, sending DAG order isn't the optimal send order for servers: sending in storage-delta order is. But in order to enable storage-optimal send order, we'll need a storage API that handles sorting. Future commits will introduce such an API. Differential Revision: https://phab.mercurial-scm.org/D4721
Gregory Szorc - - Load All Authors

File last commit:

r32697:19b9fc40 default
r39897:db5501d9 default
Show More
revlogs.txt
229 lines | 8.1 KiB | text/plain | TextLexer
/ mercurial / help / internals / revlogs.txt
History | Annotation | Raw |Copy content |Copy permalink
Revision logs - or *revlogs* - are an append only data structure for
storing discrete entries, or *revisions*. They are the primary storage
mechanism of repository data.
Revlogs effectively model a directed acyclic graph (DAG). Each node
has edges to 1 or 2 *parent* nodes. Each node contains metadata and
the raw value for that node.
Revlogs consist of entries which have metadata and revision data.
Metadata includes the hash of the revision's content, sizes, and
links to its *parent* entries. The collective metadata is referred
to as the *index* and the revision data is the *data*.
Revision data is stored as a series of compressed deltas against previous
revisions.
Revlogs are written in an append-only fashion. We never need to rewrite
a file to insert nor do we need to remove data. Rolling back in-progress
writes can be performed by truncating files. Read locks can be avoided
using simple techniques. This means that references to other data in
the same revlog *always* refer to a previous entry.
Revlogs can be modeled as 0-indexed arrays. The first revision is
revision #0 and the second is revision #1. The revision -1 is typically
used to mean *does not exist* or *not defined*.
File Format
===========
A revlog begins with a 32-bit big endian integer holding version info
and feature flags. This integer is shared with the first revision
entry.
This integer is logically divided into 2 16-bit shorts. The least
significant half of the integer is the format/version short. The other
short holds feature flags that dictate behavior of the revlog.
Only 1 bit of the format/version short is currently used. Remaining
bits are reserved for future use.
The following values for the format/version short are defined:
0
The original revlog version.
1
RevlogNG (*next generation*). It replaced version 0 when it was
implemented in 2006.
2
In-development version incorporating accumulated knowledge and
missing features from 10+ years of revlog version 1.
57005 (0xdead)
Reserved for internal testing of new versions. No defined format
beyond 32-bit header.
The feature flags short consists of bit flags. Where 0 is the least
significant bit, the following bit offsets define flags:
0
Store revision data inline.
1
Generaldelta encoding.
2-15
Reserved for future use.
The following header values are common:
00 00 00 01
v1
00 01 00 01
v1 + inline
00 02 00 01
v1 + generaldelta
00 03 00 01
v1 + inline + generaldelta
Following the 32-bit header is the remainder of the first index entry.
Following that are remaining *index* data. Inlined revision data is
possibly located between index entries. More on this layout is described
below.
Version 1 Format
================
Version 1 (RevlogNG) begins with an index describing the revisions in
the revlog. If the ``inline`` flag is set, revision data is stored inline,
or between index entries (as opposed to in a separate container).
Each index entry is 64 bytes. The byte layout of each entry is as
follows, with byte 0 being the first byte (all data stored as big endian):
0-3 (4 bytes) (rev 0 only)
Revlog header
0-5 (6 bytes)
Absolute offset of revision data from beginning of revlog.
6-7 (2 bytes)
Bit flags impacting revision behavior. The following bit offsets define:
0: REVIDX_ISCENSORED revision has censor metadata, must be verified.
1: REVIDX_ELLIPSIS revision hash does not match its data. Used by
narrowhg
2: REVIDX_EXTSTORED revision data is stored externally.
8-11 (4 bytes)
Compressed length of revision data / chunk as stored in revlog.
12-15 (4 bytes)
Uncompressed length of revision data. This is the size of the full
revision data, not the size of the chunk post decompression.
16-19 (4 bytes)
Base or previous revision this revision's delta was produced against.
This revision holds full text (as opposed to a delta) if it points to
itself. For generaldelta repos, this is the previous revision in the
delta chain. For non-generaldelta repos, this is the base or first
revision in the delta chain.
20-23 (4 bytes)
A revision this revision is *linked* to. This allows a revision in
one revlog to be forever associated with a revision in another
revlog. For example, a file's revlog may point to the changelog
revision that introduced it.
24-27 (4 bytes)
Revision of 1st parent. -1 indicates no parent.
28-31 (4 bytes)
Revision of 2nd parent. -1 indicates no 2nd parent.
32-63 (32 bytes)
Hash of revision's full text. Currently, SHA-1 is used and only
the first 20 bytes of this field are used. The rest of the bytes
are ignored and should be stored as \0.
If inline revision data is being stored, the compressed revision data
(of length from bytes offset 8-11 from the index entry) immediately
follows the index entry. There is no header on the revision data. There
is no padding between it and the index entries before and after.
If revision data is not inline, then raw revision data is stored in a
separate byte container. The offsets from bytes 0-5 and the compressed
length from bytes 8-11 define how to access this data.
The first 4 bytes of the revlog are shared between the revlog header
and the 6 byte absolute offset field from the first revlog entry.
Version 2 Format
================
(In development. Format not finalized or stable.)
Version 2 is currently identical to version 1. This will obviously
change.
Delta Chains
============
Revision data is encoded as a chain of *chunks*. Each chain begins with
the compressed original full text for that revision. Each subsequent
*chunk* is a *delta* against the previous revision. We therefore call
these chains of chunks/deltas *delta chains*.
The full text for a revision is reconstructed by loading the original
full text for the base revision of a *delta chain* and then applying
*deltas* until the target revision is reconstructed.
*Delta chains* are limited in length so lookup time is bound. They are
limited to ~2x the length of the revision's data. The linear distance
between the base chunk and the final chunk is also limited so the
amount of read I/O to load all chunks in the delta chain is bound.
Deltas and delta chains are either computed against the previous
revision in the revlog or another revision (almost certainly one of
the parents of the revision). Historically, deltas were computed against
the previous revision. The *generaldelta* revlog feature flag (enabled
by default in Mercurial 3.7) activates the mode where deltas are
computed against an arbitrary revision (almost certainly a parent revision).
File Storage
============
Revlogs logically consist of an index (metadata of entries) and
revision data. This data may be stored together in a single file or in
separate files. The mechanism used is indicated by the ``inline`` feature
flag on the revlog.
Mercurial's behavior is to use inline storage until a revlog reaches a
certain size, at which point it will be converted to non-inline. The
reason there is a size limit on inline storage is to establish an upper
bound on how much data must be read to load the index. It would be a waste
to read tens or hundreds of extra megabytes of data just to access the
index data.
The actual layout of revlog files on disk is governed by the repository's
*store format*. Typically, a ``.i`` file represents the index revlog
(possibly containing inline data) and a ``.d`` file holds the revision data.
Revision Entries
================
Revision entries consist of an optional 1 byte header followed by an
encoding of the revision data. The headers are as follows:
\0 (0x00)
Revision data is the entirety of the entry, including this header.
u (0x75)
Raw revision data follows.
x (0x78)
zlib (RFC 1950) data.
The 0x78 value is actually the first byte of the zlib header (CMF byte).
Hash Computation
================
The hash of the revision is stored in the index and is used both as a primary
key and for data integrity verification.
Currently, SHA-1 is the only supported hashing algorithm. To obtain the SHA-1
hash of a revision:
1. Hash the parent nodes
2. Hash the fulltext of the revision
The 20 byte node ids of the parents are fed into the hasher in ascending order.