On FreeBSD, this mode is not supported. But since
3a251bac0d1a (trace2:
only include "fsync" events if we git_fsync(), 2022-07-18) t5351 will
fail if this mode is unsupported.
Let's address this in the minimal fashion, by detecting that that mode
is unsupported and expecting a different count of hardware flushes in
that case.
This fixes the CI/PR builds on FreeBSD again.
Note: A better way would be to test only what is relevant in t5351.6
"unpack big object in stream (core.fsyncmethod=batch)" again instead of
blindly comparing the output against some exact text. But that would
pretty much revert the idea of above-mentioned commit, and that commit
was _just_ accepted into Git's main branch so one must assume that it
was intentional.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
*/
if (!bulk_fsync_objdir ||
git_fsync(fd, FSYNC_WRITEOUT_ONLY) < 0) {
+ if (errno == ENOSYS)
+ warning(_("core.fsyncMethod = batch is unsupported on this platform"));
fsync_or_die(fd, filename);
}
}
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" \
GIT_TEST_FSYNC=true \
git -C dest.git $BATCH_CONFIGURATION unpack-objects <pack-$PACK.pack &&
- check_fsync_events trace2.txt <<-\EOF &&
+ if grep "core.fsyncMethod = batch is unsupported" trace2.txt
+ then
+ flush_count=7
+ else
+ flush_count=1
+ fi &&
+ check_fsync_events trace2.txt <<-EOF &&
"key":"fsync/writeout-only","value":"6"
- "key":"fsync/hardware-flush","value":"1"
+ "key":"fsync/hardware-flush","value":"$flush_count"
EOF
test_dir_is_empty dest.git/objects/pack &&