主页 / computer / 问题 / 1712609
Accepted
DhP
Asked: 2022-03-25 10:01:53 +0800 CST

'du' 和 'dd' 在 BTRFS 磁盘上的奇怪行为显示为 0 文件大小。有人对此有一些线索或想法吗？

  • 772

一直在修补 btrfs，考虑从 ext4 迁移到那个。

但是，当想要比较 R/W 速度时，我似乎在 btrfs 磁盘上遇到了一个（至少对我而言）不寻常的行为du，它显然没有以与我的 ext4 上的文件相同的方式报告文件大小.

（为挪威语言环境道歉。尽管大多数人可能对英语输出足够熟悉以了解发生了什么）

制作测试文件

  1. dd我在已安装的btrfs磁盘上创建了一个 5GB 的“测试文件”：

    $ sudo dd if=/dev/urandom of=5G_dd_test_file.tmp bs=1 count=0 seek=5G
0+0 oppføringer inn
0+0 oppføringer ut
0 byte kopiert, 0,00393248 s, 0,0 kB/s

  2. fallocate以类似的方式，我在同一位置创建了一个测试文件：

    $ sudo fallocate -l 5G 5G_fallocate_test_file.tmp

  3. ls确认他们都在那里：

    $ ls
5G_dd_test_file.tmp  5G_fallocate_test_file.tmp

du行为怪异..（？）

大小输出du <file>：

$ sudo du 5G_dd_test_file.tmp 
0   5G_dd_test_file.tmp

$ sudo du 5G_fallocate_test_file.tmp 
5242880 5G_fallocate_test_file.tmp

注意 dd 生成的文件上的 0 文件大小

相比之下，ls在stat相同的文件上：

$ ls -l *.tmp
-rw-r--r-- 1 root root 5368709120 mars  24 18:07 5G_dd_test_file.tmp
-rw-r--r-- 1 root root 5368709120 mars  24 18:12 5G_fallocate_test_file.tmp

$ stat *.tmp
  Fil: 5G_dd_test_file.tmp
  Størrelse: 5368709120[tab]Blokker: 0          IO Blokk: 4096   vanlig fil
Device: 0,40    Inode: 258         Links: 1
Tilgang: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Tilgang: 2022-03-24 18:07:34.646755042 +0100
Omgjøring: 2022-03-24 18:07:34.646755042 +0100
Endring: 2022-03-24 18:07:34.646755042 +0100
 Fødsel: 2022-03-24 18:07:34.646755042 +0100
  Fil: 5G_fallocate_test_file.tmp
  Størrelse: 5368709120[tab]Blokker: 10485760   IO Blokk: 4096   vanlig fil
Device: 0,40    Inode: 259         Links: 1
Tilgang: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Tilgang: 2022-03-24 18:12:11.768422242 +0100
Omgjøring: 2022-03-24 18:12:11.768422242 +0100
Endring: 2022-03-24 18:12:11.768422242 +0100
 Fødsel: 2022-03-24 18:12:11.768422242 +0100

但是，如果我在执行显示为 0大小的相同生成文件时将-b参数添加到du （通常不需要） 。然后似乎照常行事。dd du

$ sudo du -b 5G_dd_test_file.tmp
5368709120  5G_dd_test_file.tmp

du（？）的另一个奇怪之处

所以只是出于好奇，我决定简单地gzip从以下文件中获取文件dd：

$ sudo gzip 5G_dd_test_file.tmp

$ sudo du 5G_dd_test_file.tmp.gz
5092    5G_dd_test_file.tmp.gz

现在它显示一个非零大小..

$ sudo ls -l 5G_dd_test_file.tmp.gz
-rw-r--r-- 1 root root 5210230 mars  24 18:07 5G_dd_test_file.tmp.gz

sudo stat 5G_dd_test_file.tmp.gz
  Fil: 5G_dd_test_file.tmp.gz
  Størrelse: 5210230   [tab]Blokker: 10184      IO Blokk: 4096   vanlig fil
Device: 0,40    Inode: 260         Links: 1
Tilgang: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Tilgang: 2022-03-24 18:07:34.646755042 +0100
Omgjøring: 2022-03-24 18:07:34.646755042 +0100
Endring: 2022-03-24 18:43:41.061926016 +0100
 Fødsel: 2022-03-24 18:42:27.554141544 +0100

问题是

  • 这是正常的行为并且实际上是可以预期的吗？
  • 如果不是，这可能会破坏依赖du回报的脚本或程序吗？
linux filesystems

1 个回答

  1. Best Answer

    这是正常的行为并且实际上是可以预期的吗？

    基本上是的。

    在创建文件时使用dd seek=…是一种创建稀疏文件的方法。使用dd seek=…和写入任何内容 ( count=0) 是创建完全稀疏文件的一种方式。

    […] 稀疏文件是一种计算机文件，当文件本身为部分空时，它会尝试更有效地使用文件系统空间。这是通过将表示空块的简短信息（元数据）写入数据存储介质而不是构成块的实际“空”空间来实现的，从而消耗更少的存储空间。仅当块包含“真实”（非空）数据时，才将完整块大小作为实际大小写入媒体。

    我更喜欢的方式是 with truncate。另一方面，它的主要目的fallocate是实际分配块。fallocate为您创建了一个非稀疏文件。

    du报告磁盘使用情况。完全稀疏的文件对数据使用零块。它只是一个分配了零块的目录条目。

    您gzip创建了一个非稀疏文件。没有完全稀疏的文件可以是有效的 gzip 存档，因为完全稀疏的文件在读取时返回空字节，但 gzip 标头单独包含非空字节。此外，我不希望任何 gzip 存档（能够）甚至部分稀疏，因为零块（即假设的稀疏部分）几乎可以毫不费力地高度压缩，并且它们的存在意味着gzip它的工作。

    这可能会破坏依赖du回报的脚本或程序吗？

    不，除非脚本du在应该使用时使用du -bor wc -c; 但这是脚本中的一个错误。

    用于du它的设计用途。这里有一些见解：为什么有这么多不同的方法来衡量磁盘使用情况？

    Ext4 也支持稀疏文件。使用您的dd命令，我在我的 ext4 文件系统和我的 btrfs 文件系统中分别创建了一个完全稀疏的文件。整个“问题”绝对不是关于 ext4 vs btrfs。

    • 3

相关问题