linux 将 100GB 标准输出重定向到文件失败

Question

我有这个命令可以将超过 100GB 的数据写入文件。

zfs send snap1 > file

这个过程几个小时后似乎出现了问题。例如，如果我运行该作业两次，输出会略有不同。如果我尝试使用

处理文件

zfs receive snap2 < file

几个小时后报告错误。

出于调试目的，我猜测 shell 重定向中存在一些低概率的失败。还有其他人遇到过重定向大量数据的问题吗？关于如何继续的任何建议？

调试这个过程很乏味，因为小例子可以工作，而运行大例子每次需要 3 个小时以上。

之前我尝试过管道:

zfs send snap1| zfs receive snap2

然而，对于更小的例子，这总是失败，为此

zfs send snap1 > file; zfs receive snap2 < file

成功了。 (我对此提出了一个问题，但没有得到有用的答复。)这是我怀疑 shell 的另一个原因。

谢谢。

Answer 1

与 zfs 中的错误或使用方式的问题相比，shell(或操作系统)中的故障的概率可以忽略不计。

只需几分钟即可检验您的假设:编译这个愚蠢的程序:

#include<unistd.h>
#include<string.h>

#define BUF 1<<20
#define INPUT 56

int main(int argc, char* argv[]) {
  char buf[BUF], rbuf[BUF], *a, *b;
  int len, i;
  memset(buf, INPUT, sizeof(buf));
  if (argc == 1)
  {
    while ((len = read(0, rbuf, sizeof(rbuf))) > 0)
    {
      a = buf; b = rbuf;
      for (i = 0; i < len; ++i)
      {
        if (*a != *b)
          return 1;
        ++a; ++b;
      }
    }
  }
  else
  {
    while (write(1, buf, sizeof(buf)) > 0);
  }
  return 0;
}

然后尝试mkfifo a; ./a.out w > a在 shell 中和 pv < a | ./a.out在另一张照片中，看看需要多长时间才能翻转。

它应该相对较快地进入 TiB 区域...