除了在 "
Git: fatal: fsync error on 'sha1 file': Bad file descriptor" 中提到的所有权/驱动器映射问题之外,您实际上可以知道哪个文件有问题。
创建松散对象文件时,我们没有报告我们无法完成
fsync
的确切文件名,即使这些信息是可以轻松获取的,但这已经在 Git 2.36(2022年第二季度)中得到了纠正。
查看
提交 c4e707f(2022年3月30日),作者为
Neeraj Singh(neerajsi-msft
)。
(由Junio C Hamano -- gitster
--合并于提交 98f6a3a,2022年4月4日)
报告者:Ævar Arnfjörð Bjarmason
签署者:Neeraj Singh
如果我们在尝试同步松散的对象文件时死机,请传递我们正在尝试同步的实际文件名。
这对于试图诊断失败原因的用户来说可能更有帮助,而不是以前的“松散对象文件”字符串。
它还避免了将松散对象与具有实际路径的其他内容的die
消息翻译不同的任何问题。
fatal: fsync error on 'loose object file': Bad file descriptor
但是(Git 2.36+,2022年第二季度):
fatal: fsync error on 'path/to/file': Bad file descriptor
此外,自 Git 2.36(2022 年第二季度)起,您可以使用 trace2 添加更多细节,
trace2
代码已经学会报告
fsync
操作的统计信息。请参见
commit 9a49876(2022 年 3 月 30 日),由
Neeraj Singh (neerajsi-msft
) 提交。(
已由 Junio C Hamano -- gitster
-- 合并至 commit fe496dc,2022 年 4 月 4 日)
trace2
: 为 fsync
操作添加统计信息
签署者:Neeraj Singh
添加一些全局的 trace2 统计信息,用于记录 Git 进程生命周期内执行的
fsyncs
数量。这些统计信息将作为
trace2_cmd_exit_fl
的一部分打印出来,我们可能还想在此处打印其他跨领域的统计信息。
fsync the_repository fsync/writeout-only count_fsync_writeout_only
fsync the_repository fsync/hardware-flush count_fsync_hardware_flush
Git 2.38(2022年第三季度)现在在其值全部为零时省略与fsync相关的trace2条目。
请参见
commit 3a251ba(2022年7月18日),作者是
Ævar Arnfjörð Bjarmason(avar
)。
(由Junio C Hamano -- gitster
--于commit 7c7719a,2022年7月27日合并)
trace2
: 只有在我们调用
git_fsync()
时才包含 "
fsync
" 事件。
签名:Ævar Arnfjörð Bjarmason
修复在
9a49876中添加的过度冗长的trace2日志(“
trace2
: add stats for fsync operations”,2022年3月30日,Git v2.36.0-rc0 -
merge)(首次发布于v2.36.0)。自那时起,每个"
git
"命令调用都包括这些"data"事件,尽管我们只会在
core.fsyncMethod=batch
下使用这些事件,并且即使我们将对象数据写入磁盘,也只有非零值。请参见
c0f4752(“
core.fsyncmethod
: batched disk flushes for loose-objects”,2022年4月4日,Git v2.37.0-rc0 --
merge列在
batch #7中)了解该功能。由于我们需要缩进
trace2_data_intmax()
行,因此让我们引入辅助变量以确保我们的结果行不会超过CodingGuidelines的建议。这要求将它们包装两次或引入短暂的一次性变量名称,我们选择后者。结果是例如“
git version
”
(man)之前会发出总共6个带有
GIT_TRACE2_EVENT
目标(版本、开始、
cmd_ancestry
、
cmd_name
、退出、atexit)的trace2事件,但之后会发出8个。我们在“退出”事件之前会发出2个"data"事件。我们没有发现这一点的原因是
a15860d中添加的trace2单元测试(
trace2
: t/helper/test-trace2,2019年2月22日,Git v2.22.0-rc0 --
merge列在
batch #2中)将不关心的任何"data"事件都省略了。让我们使trace2测试更加严格,并在“
t/t0212/parse_events.perl
”中进一步附加任何我们不知道的新事件类型。由于我们只调用“
test-tool trace2
”,因此不能保证我们将来不会记录其他过度冗长的事件,但我们至少会注意到每次使用trace2的JSON目标记录任何内容时是否开始发出问题事件。我们排除了“data_json”事件类型,否则我们会因
353d3d7中添加的日志(“
trace2
: collect Windows-specific process information”,2019年2月22日,Git v2.22.0-rc0 --
merge列在
batch #2中)而在“win测试”和“win+VS测试”CI上失败。看起来那个日志应该真正使用
trace2_cmd_ancestry()
,而后者是在
2f732bf中引入的(“
tr2
: log parent process name”,2021年7月21日,Git v2.34.0-rc0 --
merge列在
batch #1中),但现在我们先不管它。需要对
aaf8122进行修复(“
unpack-objects
: use
stream_loose_object()
to unpack large objects”,2022年6月11日,Git v2.38.0 --
merge列在
batch #3中),因为我们正在更改如上所述的这些事件的行为。由于我们总是发出“hardware-flush”事件,因此在
aaf8122中添加的测试并没有测试除了无条件记录该trace2数据之外的任何内容。即使“
core.fsyncMethod