我不确定在这里提这个问题是否合适。如果不合适，请随时把我引导到合适的地方。

我一直在向一个我经常使用的GitLab远程仓库推送几个提交。但是从昨天开始，我的推送尝试一直卡住。我的终端显示如下。

% git push origin main
Enumerating objects: 27, done.
Counting objects: 100% (27/27), done.
Delta compression using up to 12 threads
Compressing objects: 100% (22/22), done.
Writing objects: 100% (22/22), 845.47 KiB | 5.91 MiB/s, done.
Total 22 (delta 17), reused 0 (delta 0), pack-reused 0 (from 0)

根据 Writing objects: 100%，我相信这并不是与远端的连接或认证相关的问题。我可以让终端在这种状态下保持很长时间，它始终不会回到命令提示符。如果我用Command-C终止进程，终端会按预期返回到命令提示符，但远端显示实际并未完成推送。

我原本以为这可能与另一位用户的合并请求有关，该请求处于打开状态但失败——也许我试图推送的主分支正因为另一个变更（合并）正在进行而被锁定。然而，关闭那个合并请求并没有解决这个问题。

我对GitLab服务器的访问仅限于我正在处理的仓库的拥有者，因此我怀疑从那边能做的排错也不会有太多。

解决方案

Git不是在卡住，它在等待操作系统确认所有数据实际已经写入存储介质。

说真的：一次写入被接受只需要微秒级；写入到存储介质需要毫秒级。这大约相差一千倍，且情况更糟：这段延迟的大部分来自于“每次独立的操作”，因此如果操作系统能够把大约一百次写入合并执行，那么完成它们所需的时间就能节省大约一百毫秒左右。

现在：在某些与Windows兼容的硬件组合中，我曾见过一个小故障，我已不太记得具体情况，但解决办法是关闭SSD的写缓存。设备管理器中，选择你的驱动器，属性，策略，关闭写缓存，这听起来也差不多对。

这在我之前的机器上也起作用，那块便宜的SSD在几秒的持续且快速的写入后，写速降到了荒谬的10MB/s，关闭写缓存后，最低写速提升到了大约150MB/s左右。