2011-10-28 23:48:40 +02:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2011, Google Inc.
|
|
|
|
*/
|
2014-09-14 09:40:45 +02:00
|
|
|
#include "cache.h"
|
2011-10-28 23:48:40 +02:00
|
|
|
#include "bulk-checkin.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 07:20:09 +02:00
|
|
|
#include "lockfile.h"
|
2018-03-23 18:45:21 +01:00
|
|
|
#include "repository.h"
|
2011-10-28 23:48:40 +02:00
|
|
|
#include "csum-file.h"
|
|
|
|
#include "pack.h"
|
2014-03-03 10:24:29 +01: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 07:20:09 +02:00
|
|
|
#include "string-list.h"
|
|
|
|
#include "tmp-objdir.h"
|
2017-08-19 00:20:26 +02:00
|
|
|
#include "packfile.h"
|
2018-05-16 01:42:15 +02:00
|
|
|
#include "object-store.h"
|
2011-10-28 23:48:40 +02:00
|
|
|
|
2022-04-05 07:20:08 +02:00
|
|
|
static int odb_transaction_nesting;
|
2011-10-28 23:48:40 +02: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 07:20:09 +02:00
|
|
|
static struct tmp_objdir *bulk_fsync_objdir;
|
|
|
|
|
2022-04-05 07:20:07 +02:00
|
|
|
static struct bulk_checkin_packfile {
|
2011-10-28 23:48:40 +02:00
|
|
|
char *pack_tmp_name;
|
2018-02-01 03:18:46 +01:00
|
|
|
struct hashfile *f;
|
2011-10-28 23:48:40 +02: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 07:20:07 +02:00
|
|
|
} bulk_checkin_packfile;
|
2011-10-28 23:48:40 +02:00
|
|
|
|
2021-09-10 01:24:56 +02: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 01:17:38 +02:00
|
|
|
NULL, pack_idx_opts, hash, &idx_tmp_name);
|
2021-09-10 01:24:56 +02:00
|
|
|
rename_tmp_packfile_idx(basename, &idx_tmp_name);
|
|
|
|
|
|
|
|
free(idx_tmp_name);
|
|
|
|
}
|
|
|
|
|
2022-04-05 07:20:07 +02:00
|
|
|
static void flush_bulk_checkin_packfile(struct bulk_checkin_packfile *state)
|
2011-10-28 23:48:40 +02:00
|
|
|
{
|
2021-09-10 01:24:32 +02:00
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
2014-03-03 10:24:29 +01:00
|
|
|
struct strbuf packname = STRBUF_INIT;
|
2011-10-28 23:48:40 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!state->f)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (state->nr_written == 0) {
|
|
|
|
close(state->f->fd);
|
|
|
|
unlink(state->pack_tmp_name);
|
|
|
|
goto clear_exit;
|
|
|
|
} else if (state->nr_written == 1) {
|
2022-03-10 23:43:21 +01:00
|
|
|
finalize_hashfile(state->f, hash, FSYNC_COMPONENT_PACK,
|
|
|
|
CSUM_HASH_IN_STREAM | CSUM_FSYNC | CSUM_CLOSE);
|
2011-10-28 23:48:40 +02:00
|
|
|
} else {
|
2022-03-10 23:43:21 +01:00
|
|
|
int fd = finalize_hashfile(state->f, hash, FSYNC_COMPONENT_PACK, 0);
|
2021-09-10 01:24:32 +02:00
|
|
|
fixup_pack_header_footer(fd, hash, state->pack_tmp_name,
|
|
|
|
state->nr_written, hash,
|
2011-10-28 23:48:40 +02:00
|
|
|
state->offset);
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
2021-09-10 01:24:37 +02:00
|
|
|
strbuf_addf(&packname, "%s/pack/pack-%s.", get_object_directory(),
|
|
|
|
hash_to_hex(hash));
|
2014-03-03 10:24:29 +01:00
|
|
|
finish_tmp_packfile(&packname, state->pack_tmp_name,
|
2011-10-28 23:48:40 +02:00
|
|
|
state->written, state->nr_written,
|
2021-09-10 01:24:32 +02:00
|
|
|
&state->pack_idx_opts, hash);
|
2011-10-28 23:48:40 +02:00
|
|
|
for (i = 0; i < state->nr_written; i++)
|
|
|
|
free(state->written[i]);
|
|
|
|
|
|
|
|
clear_exit:
|
|
|
|
free(state->written);
|
|
|
|
memset(state, 0, sizeof(*state));
|
|
|
|
|
2014-03-03 10:24:29 +01:00
|
|
|
strbuf_release(&packname);
|
2011-10-28 23:48:40 +02:00
|
|
|
/* Make objects we just wrote available to ourselves */
|
2018-03-23 18:45:21 +01:00
|
|
|
reprepare_packed_git(the_repository);
|
2011-10-28 23:48:40 +02: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 07:20:09 +02: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.
|
|
|
|
*/
|
|
|
|
strbuf_addf(&temp_path, "%s/bulk_fsync_XXXXXX", get_object_directory());
|
|
|
|
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 07:20:07 +02:00
|
|
|
static int already_written(struct bulk_checkin_packfile *state, struct object_id *oid)
|
2011-10-28 23:48:40 +02:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* The object may already exist in the repository */
|
2019-01-07 09:37:54 +01:00
|
|
|
if (has_object_file(oid))
|
2011-10-28 23:48:40 +02: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-28 23:22:40 +02:00
|
|
|
if (oideq(&state->written[i]->oid, oid))
|
2011-10-28 23:48:40 +02: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.
|
|
|
|
*/
|
2022-04-05 07:20:07 +02:00
|
|
|
static int stream_to_pack(struct bulk_checkin_packfile *state,
|
2018-02-01 03:18:48 +01:00
|
|
|
git_hash_ctx *ctx, off_t *already_hashed_to,
|
2011-10-28 23:48:40 +02:00
|
|
|
int fd, size_t size, enum object_type type,
|
|
|
|
const char *path, unsigned flags)
|
|
|
|
{
|
|
|
|
git_zstream s;
|
2021-06-10 18:48:30 +02:00
|
|
|
unsigned char ibuf[16384];
|
2011-10-28 23:48:40 +02: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);
|
|
|
|
|
encode_in_pack_object_header: respect output buffer length
The encode_in_pack_object_header() writes a variable-length
header to an output buffer, but it doesn't actually know
long the buffer is. At first glance, this looks like it
might be possible to overflow.
In practice, this is probably impossible. The smallest
buffer we use is 10 bytes, which would hold the header for
an object up to 2^67 bytes. Obviously we're not likely to
see such an object, but we might worry that an object could
lie about its size (causing us to overflow before we realize
it does not actually have that many bytes). But the argument
is passed as a uintmax_t. Even on systems that have __int128
available, uintmax_t is typically restricted to 64-bit by
the ABI.
So it's unlikely that a system exists where this could be
exploited. Still, it's easy enough to use a normal out/len
pair and make sure we don't write too far. That protects the
hypothetical 128-bit system, makes it harder for callers to
accidentally specify a too-small buffer, and makes the
resulting code easier to audit.
Note that the one caller in fast-import tried to catch such
a case, but did so _after_ the call (at which point we'd
have already overflowed!). This check can now go away.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24 18:26:40 +01:00
|
|
|
hdrlen = encode_in_pack_object_header(obuf, sizeof(obuf), type, size);
|
2011-10-28 23:48:40 +02: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 08:02:11 +02: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-28 23:48:40 +02: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 03:18:48 +01:00
|
|
|
the_hash_algo->update_fn(ctx, ibuf, hsize);
|
2011-10-28 23:48:40 +02: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 03:18:46 +01:00
|
|
|
hashwrite(state->f, obuf, written);
|
2011-10-28 23:48:40 +02: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 07:20:07 +02:00
|
|
|
static void prepare_to_stream(struct bulk_checkin_packfile *state,
|
2011-10-28 23:48:40 +02: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");
|
|
|
|
}
|
|
|
|
|
2022-04-05 07:20:07 +02:00
|
|
|
static int deflate_to_pack(struct bulk_checkin_packfile *state,
|
2018-03-12 03:27:21 +01:00
|
|
|
struct object_id *result_oid,
|
2011-10-28 23:48:40 +02:00
|
|
|
int fd, size_t size,
|
|
|
|
enum object_type type, const char *path,
|
|
|
|
unsigned flags)
|
|
|
|
{
|
|
|
|
off_t seekback, already_hashed_to;
|
2018-02-01 03:18:48 +01:00
|
|
|
git_hash_ctx ctx;
|
2011-10-28 23:48:40 +02:00
|
|
|
unsigned char obuf[16384];
|
|
|
|
unsigned header_len;
|
2019-09-06 00:52:49 +02:00
|
|
|
struct hashfile_checkpoint checkpoint = {0};
|
2011-10-28 23:48:40 +02: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 00:48:25 +01:00
|
|
|
header_len = format_object_header((char *)obuf, sizeof(obuf),
|
|
|
|
type, size);
|
2018-02-01 03:18:48 +01:00
|
|
|
the_hash_algo->init_fn(&ctx);
|
|
|
|
the_hash_algo->update_fn(&ctx, obuf, header_len);
|
2011-10-28 23:48:40 +02:00
|
|
|
|
|
|
|
/* Note: idx is non-NULL when we are writing */
|
|
|
|
if ((flags & HASH_WRITE_OBJECT) != 0)
|
2021-03-13 17:17:22 +01:00
|
|
|
CALLOC_ARRAY(idx, 1);
|
2011-10-28 23:48:40 +02:00
|
|
|
|
|
|
|
already_hashed_to = 0;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
prepare_to_stream(state, flags);
|
|
|
|
if (idx) {
|
2018-02-01 03:18:46 +01:00
|
|
|
hashfile_checkpoint(state->f, &checkpoint);
|
2011-10-28 23:48:40 +02:00
|
|
|
idx->offset = state->offset;
|
|
|
|
crc32_begin(state->f);
|
|
|
|
}
|
|
|
|
if (!stream_to_pack(state, &ctx, &already_hashed_to,
|
|
|
|
fd, size, type, path, flags))
|
|
|
|
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 11:38:39 +02:00
|
|
|
BUG("should not happen");
|
2018-02-01 03:18:46 +01:00
|
|
|
hashfile_truncate(state->f, &checkpoint);
|
2011-10-28 23:48:40 +02:00
|
|
|
state->offset = checkpoint.offset;
|
2022-04-05 07:20:07 +02:00
|
|
|
flush_bulk_checkin_packfile(state);
|
2011-10-28 23:48:40 +02:00
|
|
|
if (lseek(fd, seekback, SEEK_SET) == (off_t) -1)
|
|
|
|
return error("cannot seek back");
|
|
|
|
}
|
2021-04-26 03:02:53 +02:00
|
|
|
the_hash_algo->final_oid_fn(result_oid, &ctx);
|
2011-10-28 23:48:40 +02:00
|
|
|
if (!idx)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
idx->crc32 = crc32_end(state->f);
|
2018-03-12 03:27:21 +01:00
|
|
|
if (already_written(state, result_oid)) {
|
2018-02-01 03:18:46 +01:00
|
|
|
hashfile_truncate(state->f, &checkpoint);
|
2011-10-28 23:48:40 +02:00
|
|
|
state->offset = checkpoint.offset;
|
|
|
|
free(idx);
|
|
|
|
} else {
|
2018-03-12 03:27:21 +01:00
|
|
|
oidcpy(&idx->oid, result_oid);
|
2011-10-28 23:48:40 +02: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 07:20:09 +02: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 14:28:43 +02: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 07:20:09 +02:00
|
|
|
fsync_or_die(fd, filename);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-12 03:27:21 +01:00
|
|
|
int index_bulk_checkin(struct object_id *oid,
|
2011-10-28 23:48:40 +02:00
|
|
|
int fd, size_t size, enum object_type type,
|
|
|
|
const char *path, unsigned flags)
|
|
|
|
{
|
2022-04-05 07:20:07 +02:00
|
|
|
int status = deflate_to_pack(&bulk_checkin_packfile, oid, fd, size, type,
|
2011-10-28 23:48:40 +02:00
|
|
|
path, flags);
|
2022-04-05 07:20:08 +02:00
|
|
|
if (!odb_transaction_nesting)
|
2022-04-05 07:20:07 +02:00
|
|
|
flush_bulk_checkin_packfile(&bulk_checkin_packfile);
|
2011-10-28 23:48:40 +02:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2022-04-05 07:20:08 +02:00
|
|
|
void begin_odb_transaction(void)
|
2011-10-28 23:48:40 +02:00
|
|
|
{
|
2022-04-05 07:20:08 +02:00
|
|
|
odb_transaction_nesting += 1;
|
2011-10-28 23:48:40 +02:00
|
|
|
}
|
|
|
|
|
2022-04-05 07:20:08 +02:00
|
|
|
void flush_odb_transaction(void)
|
2011-10-28 23:48:40 +02: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 07:20:09 +02:00
|
|
|
flush_batch_fsync();
|
2022-04-05 07:20:07 +02:00
|
|
|
flush_bulk_checkin_packfile(&bulk_checkin_packfile);
|
2011-10-28 23:48:40 +02:00
|
|
|
}
|
2022-04-05 07:20:08 +02: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-28 23:48:40 +02:00
|
|
|
}
|