2011-10-29 05:48:40 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2011, Google Inc.
|
|
|
|
*/
|
global: introduce `USE_THE_REPOSITORY_VARIABLE` macro
Use of the `the_repository` variable is deprecated nowadays, and we
slowly but steadily convert the codebase to not use it anymore. Instead,
callers should be passing down the repository to work on via parameters.
It is hard though to prove that a given code unit does not use this
variable anymore. The most trivial case, merely demonstrating that there
is no direct use of `the_repository`, is already a bit of a pain during
code reviews as the reviewer needs to manually verify claims made by the
patch author. The bigger problem though is that we have many interfaces
that implicitly rely on `the_repository`.
Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code
units to opt into usage of `the_repository`. The intent of this macro is
to demonstrate that a certain code unit does not use this variable
anymore, and to keep it from new dependencies on it in future changes,
be it explicit or implicit
For now, the macro only guards `the_repository` itself as well as
`the_hash_algo`. There are many more known interfaces where we have an
implicit dependency on `the_repository`, but those are not guarded at
the current point in time. Over time though, we should start to add
guards as required (or even better, just remove them).
Define the macro as required in our code units. As expected, most of our
code still relies on the global variable. Nearly all of our builtins
rely on the variable as there is no way yet to pass `the_repository` to
their entry point. For now, declare the macro in "biultin.h" to keep the
required changes at least a little bit more contained.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-14 14:50:23 +08:00
|
|
|
|
|
|
|
#define USE_THE_REPOSITORY_VARIABLE
|
|
|
|
|
2023-04-11 15:41:54 +08:00
|
|
|
#include "git-compat-util.h"
|
2011-10-29 05:48:40 +08:00
|
|
|
#include "bulk-checkin.h"
|
2023-03-21 14:26:03 +08:00
|
|
|
#include "environment.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-02-24 08:09:27 +08:00
|
|
|
#include "hex.h"
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
#include "lockfile.h"
|
2018-03-24 01:45:21 +08:00
|
|
|
#include "repository.h"
|
2011-10-29 05:48:40 +08:00
|
|
|
#include "csum-file.h"
|
|
|
|
#include "pack.h"
|
2014-03-03 17:24:29 +08:00
|
|
|
#include "strbuf.h"
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
#include "tmp-objdir.h"
|
2017-08-19 06:20:26 +08:00
|
|
|
#include "packfile.h"
|
2023-04-11 15:41:53 +08:00
|
|
|
#include "object-file.h"
|
2023-05-16 14:34:06 +08:00
|
|
|
#include "object-store-ll.h"
|
2011-10-29 05:48:40 +08:00
|
|
|
|
2022-04-05 13:20:08 +08:00
|
|
|
static int odb_transaction_nesting;
|
2011-10-29 05:48:40 +08:00
|
|
|
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
static struct tmp_objdir *bulk_fsync_objdir;
|
|
|
|
|
2022-04-05 13:20:07 +08:00
|
|
|
static struct bulk_checkin_packfile {
|
2011-10-29 05:48:40 +08:00
|
|
|
char *pack_tmp_name;
|
2018-02-01 10:18:46 +08:00
|
|
|
struct hashfile *f;
|
2011-10-29 05:48:40 +08:00
|
|
|
off_t offset;
|
|
|
|
struct pack_idx_option pack_idx_opts;
|
|
|
|
|
|
|
|
struct pack_idx_entry **written;
|
|
|
|
uint32_t alloc_written;
|
|
|
|
uint32_t nr_written;
|
2022-04-05 13:20:07 +08:00
|
|
|
} bulk_checkin_packfile;
|
2011-10-29 05:48:40 +08:00
|
|
|
|
2021-09-10 07:24:56 +08:00
|
|
|
static void finish_tmp_packfile(struct strbuf *basename,
|
|
|
|
const char *pack_tmp_name,
|
|
|
|
struct pack_idx_entry **written_list,
|
|
|
|
uint32_t nr_written,
|
|
|
|
struct pack_idx_option *pack_idx_opts,
|
|
|
|
unsigned char hash[])
|
|
|
|
{
|
|
|
|
char *idx_tmp_name = NULL;
|
|
|
|
|
|
|
|
stage_tmp_packfiles(basename, pack_tmp_name, written_list, nr_written,
|
2022-05-21 07:17:38 +08:00
|
|
|
NULL, pack_idx_opts, hash, &idx_tmp_name);
|
2021-09-10 07:24:56 +08:00
|
|
|
rename_tmp_packfile_idx(basename, &idx_tmp_name);
|
|
|
|
|
|
|
|
free(idx_tmp_name);
|
|
|
|
}
|
|
|
|
|
2022-04-05 13:20:07 +08:00
|
|
|
static void flush_bulk_checkin_packfile(struct bulk_checkin_packfile *state)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
2021-09-10 07:24:32 +08:00
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
2014-03-03 17:24:29 +08:00
|
|
|
struct strbuf packname = STRBUF_INIT;
|
2011-10-29 05:48:40 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!state->f)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (state->nr_written == 0) {
|
|
|
|
close(state->f->fd);
|
2024-08-14 14:52:03 +08:00
|
|
|
free_hashfile(state->f);
|
2011-10-29 05:48:40 +08:00
|
|
|
unlink(state->pack_tmp_name);
|
|
|
|
goto clear_exit;
|
|
|
|
} else if (state->nr_written == 1) {
|
2022-03-11 06:43:21 +08:00
|
|
|
finalize_hashfile(state->f, hash, FSYNC_COMPONENT_PACK,
|
|
|
|
CSUM_HASH_IN_STREAM | CSUM_FSYNC | CSUM_CLOSE);
|
2011-10-29 05:48:40 +08:00
|
|
|
} else {
|
2022-03-11 06:43:21 +08:00
|
|
|
int fd = finalize_hashfile(state->f, hash, FSYNC_COMPONENT_PACK, 0);
|
2021-09-10 07:24:32 +08:00
|
|
|
fixup_pack_header_footer(fd, hash, state->pack_tmp_name,
|
|
|
|
state->nr_written, hash,
|
2011-10-29 05:48:40 +08:00
|
|
|
state->offset);
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
2024-09-12 19:29:30 +08:00
|
|
|
strbuf_addf(&packname, "%s/pack/pack-%s.", repo_get_object_directory(the_repository),
|
2021-09-10 07:24:37 +08:00
|
|
|
hash_to_hex(hash));
|
2014-03-03 17:24:29 +08:00
|
|
|
finish_tmp_packfile(&packname, state->pack_tmp_name,
|
2011-10-29 05:48:40 +08:00
|
|
|
state->written, state->nr_written,
|
2021-09-10 07:24:32 +08:00
|
|
|
&state->pack_idx_opts, hash);
|
2011-10-29 05:48:40 +08:00
|
|
|
for (i = 0; i < state->nr_written; i++)
|
|
|
|
free(state->written[i]);
|
|
|
|
|
|
|
|
clear_exit:
|
2024-08-14 14:52:03 +08:00
|
|
|
free(state->pack_tmp_name);
|
2011-10-29 05:48:40 +08:00
|
|
|
free(state->written);
|
|
|
|
memset(state, 0, sizeof(*state));
|
|
|
|
|
2014-03-03 17:24:29 +08:00
|
|
|
strbuf_release(&packname);
|
2011-10-29 05:48:40 +08:00
|
|
|
/* Make objects we just wrote available to ourselves */
|
2018-03-24 01:45:21 +08:00
|
|
|
reprepare_packed_git(the_repository);
|
2011-10-29 05:48:40 +08:00
|
|
|
}
|
|
|
|
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
/*
|
|
|
|
* Cleanup after batch-mode fsync_object_files.
|
|
|
|
*/
|
|
|
|
static void flush_batch_fsync(void)
|
|
|
|
{
|
|
|
|
struct strbuf temp_path = STRBUF_INIT;
|
|
|
|
struct tempfile *temp;
|
|
|
|
|
|
|
|
if (!bulk_fsync_objdir)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Issue a full hardware flush against a temporary file to ensure
|
|
|
|
* that all objects are durable before any renames occur. The code in
|
|
|
|
* fsync_loose_object_bulk_checkin has already issued a writeout
|
|
|
|
* request, but it has not flushed any writeback cache in the storage
|
|
|
|
* hardware or any filesystem logs. This fsync call acts as a barrier
|
|
|
|
* to ensure that the data in each new object file is durable before
|
|
|
|
* the final name is visible.
|
|
|
|
*/
|
2024-09-12 19:29:30 +08:00
|
|
|
strbuf_addf(&temp_path, "%s/bulk_fsync_XXXXXX", repo_get_object_directory(the_repository));
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
temp = xmks_tempfile(temp_path.buf);
|
|
|
|
fsync_or_die(get_tempfile_fd(temp), get_tempfile_path(temp));
|
|
|
|
delete_tempfile(&temp);
|
|
|
|
strbuf_release(&temp_path);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make the object files visible in the primary ODB after their data is
|
|
|
|
* fully durable.
|
|
|
|
*/
|
|
|
|
tmp_objdir_migrate(bulk_fsync_objdir);
|
|
|
|
bulk_fsync_objdir = NULL;
|
|
|
|
}
|
|
|
|
|
2022-04-05 13:20:07 +08:00
|
|
|
static int already_written(struct bulk_checkin_packfile *state, struct object_id *oid)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* The object may already exist in the repository */
|
2023-03-28 21:58:50 +08:00
|
|
|
if (repo_has_object_file(the_repository, oid))
|
2011-10-29 05:48:40 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* Might want to keep the list sorted */
|
|
|
|
for (i = 0; i < state->nr_written; i++)
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29 05:22:40 +08:00
|
|
|
if (oideq(&state->written[i]->oid, oid))
|
2011-10-29 05:48:40 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* This is a new object we need to keep */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the contents from fd for size bytes, streaming it to the
|
|
|
|
* packfile in state while updating the hash in ctx. Signal a failure
|
|
|
|
* by returning a negative value when the resulting pack would exceed
|
|
|
|
* the pack size limit and this is not the first object in the pack,
|
|
|
|
* so that the caller can discard what we wrote from the current pack
|
|
|
|
* by truncating it and opening a new one. The caller will then call
|
|
|
|
* us again after rewinding the input fd.
|
|
|
|
*
|
|
|
|
* The already_hashed_to pointer is kept untouched by the caller to
|
|
|
|
* make sure we do not hash the same byte when we are called
|
|
|
|
* again. This way, the caller does not have to checkpoint its hash
|
|
|
|
* status before calling us just in case we ask it to call us again
|
|
|
|
* with a new pack.
|
|
|
|
*/
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
static int stream_blob_to_pack(struct bulk_checkin_packfile *state,
|
|
|
|
git_hash_ctx *ctx, off_t *already_hashed_to,
|
|
|
|
int fd, size_t size, const char *path,
|
|
|
|
unsigned flags)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
|
|
|
git_zstream s;
|
2021-06-11 00:48:30 +08:00
|
|
|
unsigned char ibuf[16384];
|
2011-10-29 05:48:40 +08:00
|
|
|
unsigned char obuf[16384];
|
|
|
|
unsigned hdrlen;
|
|
|
|
int status = Z_OK;
|
|
|
|
int write_object = (flags & HASH_WRITE_OBJECT);
|
|
|
|
off_t offset = 0;
|
|
|
|
|
|
|
|
git_deflate_init(&s, pack_compression_level);
|
|
|
|
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
hdrlen = encode_in_pack_object_header(obuf, sizeof(obuf), OBJ_BLOB, size);
|
2011-10-29 05:48:40 +08:00
|
|
|
s.next_out = obuf + hdrlen;
|
|
|
|
s.avail_out = sizeof(obuf) - hdrlen;
|
|
|
|
|
|
|
|
while (status != Z_STREAM_END) {
|
|
|
|
if (size && !s.avail_in) {
|
|
|
|
ssize_t rsize = size < sizeof(ibuf) ? size : sizeof(ibuf);
|
2017-09-27 14:02:11 +08:00
|
|
|
ssize_t read_result = read_in_full(fd, ibuf, rsize);
|
|
|
|
if (read_result < 0)
|
|
|
|
die_errno("failed to read from '%s'", path);
|
|
|
|
if (read_result != rsize)
|
2011-10-29 05:48:40 +08:00
|
|
|
die("failed to read %d bytes from '%s'",
|
|
|
|
(int)rsize, path);
|
|
|
|
offset += rsize;
|
|
|
|
if (*already_hashed_to < offset) {
|
|
|
|
size_t hsize = offset - *already_hashed_to;
|
|
|
|
if (rsize < hsize)
|
|
|
|
hsize = rsize;
|
|
|
|
if (hsize)
|
2018-02-01 10:18:48 +08:00
|
|
|
the_hash_algo->update_fn(ctx, ibuf, hsize);
|
2011-10-29 05:48:40 +08:00
|
|
|
*already_hashed_to = offset;
|
|
|
|
}
|
|
|
|
s.next_in = ibuf;
|
|
|
|
s.avail_in = rsize;
|
|
|
|
size -= rsize;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = git_deflate(&s, size ? 0 : Z_FINISH);
|
|
|
|
|
|
|
|
if (!s.avail_out || status == Z_STREAM_END) {
|
|
|
|
if (write_object) {
|
|
|
|
size_t written = s.next_out - obuf;
|
|
|
|
|
|
|
|
/* would we bust the size limit? */
|
|
|
|
if (state->nr_written &&
|
|
|
|
pack_size_limit_cfg &&
|
|
|
|
pack_size_limit_cfg < state->offset + written) {
|
|
|
|
git_deflate_abort(&s);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2018-02-01 10:18:46 +08:00
|
|
|
hashwrite(state->f, obuf, written);
|
2011-10-29 05:48:40 +08:00
|
|
|
state->offset += written;
|
|
|
|
}
|
|
|
|
s.next_out = obuf;
|
|
|
|
s.avail_out = sizeof(obuf);
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (status) {
|
|
|
|
case Z_OK:
|
|
|
|
case Z_BUF_ERROR:
|
|
|
|
case Z_STREAM_END:
|
|
|
|
continue;
|
|
|
|
default:
|
|
|
|
die("unexpected deflate failure: %d", status);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
git_deflate_end(&s);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Lazily create backing packfile for the state */
|
2022-04-05 13:20:07 +08:00
|
|
|
static void prepare_to_stream(struct bulk_checkin_packfile *state,
|
2011-10-29 05:48:40 +08:00
|
|
|
unsigned flags)
|
|
|
|
{
|
|
|
|
if (!(flags & HASH_WRITE_OBJECT) || state->f)
|
|
|
|
return;
|
|
|
|
|
|
|
|
state->f = create_tmp_packfile(&state->pack_tmp_name);
|
|
|
|
reset_pack_idx_option(&state->pack_idx_opts);
|
|
|
|
|
|
|
|
/* Pretend we are going to write only one object */
|
|
|
|
state->offset = write_pack_header(state->f, 1);
|
|
|
|
if (!state->offset)
|
|
|
|
die_errno("unable to write pack header");
|
|
|
|
}
|
|
|
|
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
static int deflate_blob_to_pack(struct bulk_checkin_packfile *state,
|
|
|
|
struct object_id *result_oid,
|
|
|
|
int fd, size_t size,
|
|
|
|
const char *path, unsigned flags)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
|
|
|
off_t seekback, already_hashed_to;
|
2018-02-01 10:18:48 +08:00
|
|
|
git_hash_ctx ctx;
|
2011-10-29 05:48:40 +08:00
|
|
|
unsigned char obuf[16384];
|
|
|
|
unsigned header_len;
|
2019-09-06 06:52:49 +08:00
|
|
|
struct hashfile_checkpoint checkpoint = {0};
|
2011-10-29 05:48:40 +08:00
|
|
|
struct pack_idx_entry *idx = NULL;
|
|
|
|
|
|
|
|
seekback = lseek(fd, 0, SEEK_CUR);
|
|
|
|
if (seekback == (off_t) -1)
|
|
|
|
return error("cannot find the current offset");
|
|
|
|
|
2022-02-05 07:48:25 +08:00
|
|
|
header_len = format_object_header((char *)obuf, sizeof(obuf),
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
OBJ_BLOB, size);
|
2018-02-01 10:18:48 +08:00
|
|
|
the_hash_algo->init_fn(&ctx);
|
|
|
|
the_hash_algo->update_fn(&ctx, obuf, header_len);
|
2023-09-01 10:09:28 +08:00
|
|
|
the_hash_algo->init_fn(&checkpoint.ctx);
|
2011-10-29 05:48:40 +08:00
|
|
|
|
|
|
|
/* Note: idx is non-NULL when we are writing */
|
|
|
|
if ((flags & HASH_WRITE_OBJECT) != 0)
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(idx, 1);
|
2011-10-29 05:48:40 +08:00
|
|
|
|
|
|
|
already_hashed_to = 0;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
prepare_to_stream(state, flags);
|
|
|
|
if (idx) {
|
2018-02-01 10:18:46 +08:00
|
|
|
hashfile_checkpoint(state->f, &checkpoint);
|
2011-10-29 05:48:40 +08:00
|
|
|
idx->offset = state->offset;
|
|
|
|
crc32_begin(state->f);
|
|
|
|
}
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
if (!stream_blob_to_pack(state, &ctx, &already_hashed_to,
|
|
|
|
fd, size, path, flags))
|
2011-10-29 05:48:40 +08:00
|
|
|
break;
|
|
|
|
/*
|
|
|
|
* Writing this object to the current pack will make
|
|
|
|
* it too big; we need to truncate it, start a new
|
|
|
|
* pack, and write into it.
|
|
|
|
*/
|
|
|
|
if (!idx)
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("should not happen");
|
2018-02-01 10:18:46 +08:00
|
|
|
hashfile_truncate(state->f, &checkpoint);
|
2011-10-29 05:48:40 +08:00
|
|
|
state->offset = checkpoint.offset;
|
2022-04-05 13:20:07 +08:00
|
|
|
flush_bulk_checkin_packfile(state);
|
2011-10-29 05:48:40 +08:00
|
|
|
if (lseek(fd, seekback, SEEK_SET) == (off_t) -1)
|
|
|
|
return error("cannot seek back");
|
|
|
|
}
|
2021-04-26 09:02:53 +08:00
|
|
|
the_hash_algo->final_oid_fn(result_oid, &ctx);
|
2011-10-29 05:48:40 +08:00
|
|
|
if (!idx)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
idx->crc32 = crc32_end(state->f);
|
2018-03-12 10:27:21 +08:00
|
|
|
if (already_written(state, result_oid)) {
|
2018-02-01 10:18:46 +08:00
|
|
|
hashfile_truncate(state->f, &checkpoint);
|
2011-10-29 05:48:40 +08:00
|
|
|
state->offset = checkpoint.offset;
|
|
|
|
free(idx);
|
|
|
|
} else {
|
2018-03-12 10:27:21 +08:00
|
|
|
oidcpy(&idx->oid, result_oid);
|
2011-10-29 05:48:40 +08:00
|
|
|
ALLOC_GROW(state->written,
|
|
|
|
state->nr_written + 1,
|
|
|
|
state->alloc_written);
|
|
|
|
state->written[state->nr_written++] = idx;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
void prepare_loose_object_bulk_checkin(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We lazily create the temporary object directory
|
|
|
|
* the first time an object might be added, since
|
|
|
|
* callers may not know whether any objects will be
|
|
|
|
* added at the time they call begin_odb_transaction.
|
|
|
|
*/
|
|
|
|
if (!odb_transaction_nesting || bulk_fsync_objdir)
|
|
|
|
return;
|
|
|
|
|
|
|
|
bulk_fsync_objdir = tmp_objdir_create("bulk-fsync");
|
|
|
|
if (bulk_fsync_objdir)
|
|
|
|
tmp_objdir_replace_primary_odb(bulk_fsync_objdir, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void fsync_loose_object_bulk_checkin(int fd, const char *filename)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If we have an active ODB transaction, we issue a call that
|
|
|
|
* cleans the filesystem page cache but avoids a hardware flush
|
|
|
|
* command. Later on we will issue a single hardware flush
|
|
|
|
* before renaming the objects to their final names as part of
|
|
|
|
* flush_batch_fsync.
|
|
|
|
*/
|
|
|
|
if (!bulk_fsync_objdir ||
|
|
|
|
git_fsync(fd, FSYNC_WRITEOUT_ONLY) < 0) {
|
2022-07-29 20:28:43 +08:00
|
|
|
if (errno == ENOSYS)
|
|
|
|
warning(_("core.fsyncMethod = batch is unsupported on this platform"));
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
fsync_or_die(fd, filename);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
int index_blob_bulk_checkin(struct object_id *oid,
|
|
|
|
int fd, size_t size,
|
|
|
|
const char *path, unsigned flags)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
bulk-checkin: only support blobs in index_bulk_checkin
As the code is written today index_bulk_checkin only accepts blobs.
Remove the enum object_type parameter and rename index_bulk_checkin to
index_blob_bulk_checkin, index_stream to index_blob_stream,
deflate_to_pack to deflate_blob_to_pack, stream_to_pack to
stream_blob_to_pack, to make this explicit.
Not supporting commits, tags, or trees has no downside as it is not
currently supported now, and commits, tags, and trees being smaller by
design do not have the problem that the problem that index_bulk_checkin
was built to solve.
Before we start adding code to support the hash function transition
supporting additional objects types in index_bulk_checkin has no real
additional cost, just an extra function parameter to know what the
object type is. Once we begin the hash function transition this is not
the case.
The hash function transition document specifies that a repository with
compatObjectFormat enabled will compute and store both the SHA-1 and
SHA-256 hash of every object in the repository.
What makes this a challenge is that it is not just an additional hash
over the same object. Instead the hash function transition document
specifies that the compatibility hash (specified with
compatObjectFormat) be computed over the equivalent object that another
git repository whose storage hash (specified with objectFormat) would
store. When comparing equivalent repositories built with different
storage hash functions, the oids embedded in objects used to refer to
other objects differ and the location of signatures within objects
differ.
As blob objects have neither oids referring to other objects nor stored
signatures their storage hash and their compatibility hash are computed
over the same object.
The other kinds of objects: trees, commits, and tags, all store oids
referring to other objects. Signatures are stored in commit and tag
objects. As oids and the tags to store signatures are not the same size
in repositories built with different storage hashes the size of the
equivalent objects are also different.
A version of index_bulk_checkin that supports more than just blobs when
computing both the SHA-1 and the SHA-256 of every object added would
need a different, and more expensive structure. The structure is more
expensive because it would be required to temporarily buffering the
equivalent object the compatibility hash needs to be computed over.
A temporary object is needed, because before a hash over an object can
computed it's object header needs to be computed. One of the members of
the object header is the entire size of the object. To know the size of
an equivalent object an entire pass over the original object needs to be
made, as trees, commits, and tags are composed of a variable number of
variable sized pieces. Unfortunately there is no formula to compute the
size of an equivalent object from just the size of the original object.
Avoid all of those future complications by limiting index_bulk_checkin
to only work on blobs.
Inspired-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26 23:58:43 +08:00
|
|
|
int status = deflate_blob_to_pack(&bulk_checkin_packfile, oid, fd, size,
|
|
|
|
path, flags);
|
2022-04-05 13:20:08 +08:00
|
|
|
if (!odb_transaction_nesting)
|
2022-04-05 13:20:07 +08:00
|
|
|
flush_bulk_checkin_packfile(&bulk_checkin_packfile);
|
2011-10-29 05:48:40 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2022-04-05 13:20:08 +08:00
|
|
|
void begin_odb_transaction(void)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
2022-04-05 13:20:08 +08:00
|
|
|
odb_transaction_nesting += 1;
|
2011-10-29 05:48:40 +08:00
|
|
|
}
|
|
|
|
|
2022-04-05 13:20:08 +08:00
|
|
|
void flush_odb_transaction(void)
|
2011-10-29 05:48:40 +08:00
|
|
|
{
|
core.fsyncmethod: batched disk flushes for loose-objects
When adding many objects to a repo with `core.fsync=loose-object`,
the cost of fsync'ing each object file can become prohibitive.
One major source of the cost of fsync is the implied flush of the
hardware writeback cache within the disk drive. This commit introduces
a new `core.fsyncMethod=batch` option that batches up hardware flushes.
It hooks into the bulk-checkin odb-transaction functionality, takes
advantage of tmp-objdir, and uses the writeout-only support code.
When the new mode is enabled, we do the following for each new object:
1a. Create the object in a tmp-objdir.
2a. Issue a pagecache writeback request and wait for it to complete.
At the end of the entire transaction when unplugging bulk checkin:
1b. Issue an fsync against a dummy file to flush the log and hardware
writeback cache, which should by now have seen the tmp-objdir writes.
2b. Rename all of the tmp-objdir files to their final names.
3b. When updating the index and/or refs, we assume that Git will issue
another fsync internal to that operation. This is not the default
today, but the user now has the option of syncing the index and there
is a separate patch series to implement syncing of refs.
On a filesystem with a singular journal that is updated during name
operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS
we would expect the fsync to trigger a journal writeout so that this
sequence is enough to ensure that the user's data is durable by the time
the git command returns. This sequence also ensures that no object files
appear in the main object store unless they are fsync-durable.
Batch mode is only enabled if core.fsync includes loose-objects. If
the legacy core.fsyncObjectFiles setting is enabled, but core.fsync does
not include loose-objects, we will use file-by-file fsyncing.
In step (1a) of the sequence, the tmp-objdir is created lazily to avoid
work if no loose objects are ever added to the ODB. We use a tmp-objdir
to maintain the invariant that no loose-objects are visible in the main
ODB unless they are properly fsync-durable. This is important since
future ODB operations that try to create an object with specific
contents will silently drop the new data if an object with the target
hash exists without checking that the loose-object contents match the
hash. Only a full git-fsck would restore the ODB to a functional state
where dataloss doesn't occur.
In step (1b) of the sequence, we issue a fsync against a dummy file
created specifically for the purpose. This method has a little higher
cost than using one of the input object files, but makes adding new
callers of this mechanism easier, since we don't need to figure out
which object file is "last" or risk sharing violations by caching the fd
of the last object file.
_Performance numbers_:
Linux - Hyper-V VM running Kernel 5.11 (Ubuntu 20.04) on a fast SSD.
Mac - macOS 11.5.1 running on a Mac mini on a 1TB Apple SSD.
Windows - Same host as Linux, a preview version of Windows 11.
Adding 500 files to the repo with 'git add' Times reported in seconds.
object file syncing | Linux | Mac | Windows
--------------------|-------|-------|--------
disabled | 0.06 | 0.35 | 0.61
fsync | 1.88 | 11.18 | 2.47
batch | 0.15 | 0.41 | 1.53
Signed-off-by: Neeraj Singh <neerajsi@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-05 13:20:09 +08:00
|
|
|
flush_batch_fsync();
|
2022-04-05 13:20:07 +08:00
|
|
|
flush_bulk_checkin_packfile(&bulk_checkin_packfile);
|
2011-10-29 05:48:40 +08:00
|
|
|
}
|
2022-04-05 13:20:08 +08:00
|
|
|
|
|
|
|
void end_odb_transaction(void)
|
|
|
|
{
|
|
|
|
odb_transaction_nesting -= 1;
|
|
|
|
if (odb_transaction_nesting < 0)
|
|
|
|
BUG("Unbalanced ODB transaction nesting");
|
|
|
|
|
|
|
|
if (odb_transaction_nesting)
|
|
|
|
return;
|
|
|
|
|
|
|
|
flush_odb_transaction();
|
2011-10-29 05:48:40 +08:00
|
|
|
}
|