是否可以在btrfs文件系统上获取文件的压缩和未压缩大小？

Question

是否有可能确定压缩大小（我假设ls -l列出的是什么）和启用了btrfs的transparent compression文件系统上文件的未压缩大小？

Answer 1

有第三方工具可以做到这一点。

https://github.com/kilobyte/compsize

用法：

ayush@devbox:/code/compsize$ sudo compsize /opt
Processed 54036 files, 42027 regular extents (42028 refs), 27150 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
Data        82%      5.3G         6.4G         6.4G       
none       100%      4.3G         4.3G         4.3G       
zlib        37%      427M         1.1G         1.1G       
lzo         56%      588M         1.0G         1.0G  

Answer 2

我无法逐个文件地回答，@ catlover2给出了文件系统的答案。但是你应该区分磁盘上的块大小和（虚拟）文件系统中的大小，ls和du不能超出文件系统，因此它们没有提供有关使用了多少磁盘块的信息，@ jiliagre --apparent-size在这里没用。

为了更好地说明这个问题，我用一个23G文件btrfs文件系统进行了测试;首先是未压缩的，然后是lzo压缩的。示例文件是虚拟机映像，压缩级别仅为0.5。它表明只有df和btrfs filesystem df可以显示压缩。

$   lvcreate vg0 test_btrfs -L 30G
Logical volume "test_btrfs" created
$ mkfs.btrfs /dev/vg0/test_btrfs
...
fs created label (null) on /dev/vg0/test_btrfs
    nodesize 16384 leafsize 16384 sectorsize 4096 size 30.00GiB
$ mount /dev/vg0/test_btrfs /tmp/test_btrfs
$ btrfs filesystem df /tmp/test_btrfs
Data, single: total=8.00MiB, used=256.00KiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=112.00KiB
Metadata, single: total=8.00MiB, used=0.00
$ cp bigfile /tmp/test_btrfs
$ btrfs filesystem df /tmp/test_btrfs
Data, single: total=24.01GiB, used=22.70GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=23.64MiB
Metadata, single: total=8.00MiB, used=0.00
$ btrfs filesystem df /tmp/test_btrfs
... unchanged!
$ cd /tmp/test_btrfs/
$ ls -l bigfile
-rw------- 1 root root 24367940096 May  4 15:03 bigfile
$ du -B1 --apparent-size bigfile
24367940096 bigfile
$ du -B1 bigfile
24367943680 bigfile
$ btrfs filesystem defragment -c bigfile
$ ls -l bigfile
-rw------- 1 root root 24367940096 May  4 15:03 bigfile
$ du -B1 --apparent-size bigfile
24367940096 bigfile
$ du -B1 bigfile
24367943680 bigfile
$ btrfs filesystem df /tmp/test_btrfs
Data, single: total=24.01GiB, used=12.90GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.00GiB, used=39.19MiB
Metadata, single: total=8.00MiB, used=0.00
$ df -BG /tmp/test_btrfs
Filesystem                 1G-blocks  Used Available Use% Mounted on
/dev/mapper/vg0-test_btrfs       30G   13G       16G  47% /tmp/test_btrfs

@ gandalf3的问题仍然没有答案，可能我们需要等待btrfs的开发（或帮助开发它！）以获得一个适当的底层磁盘阻止du为一个特殊的文件。这将是非常有用的，当我用压缩（没有强制）安装btrfs fs时我发现非常令人沮丧，不知道我的文件是否被压缩以及在哪个级别。

Answer 3

无论文件系统类型如何，文件的磁盘大小由du命令给出1，例如：

$ du -h *
732K    file
512 file1
4.0M    file2
$ du -B1 *
749568  file
512 file1
4091904 file2

磁盘大小等于文件的大小加上其元数据的大小，四舍五入到文件系统块大小。非压缩文件的磁盘大小通常略大于实际（字节数）大小。

如前所述，未压缩的尺寸由ls -l显示。它也可以由du用--apparent-size option报告;

$ du --apparent-size -h *
826K    file
64M file1
17M file2
$ du --apparent-size -B 1  *
845708  file
67108864    file1
16784836    file2

请注意，-B1和--apparent-size是GNU特定的du扩展。

1看来btrfs不遵循这条规则。如果这是真的/仍然是真的，我的理解是应该被认为是一个bug或者至少是一个POSIX non conformance。

Answer 4

我也试图回答这个问题，这就是我发现的：du -s和df产生不同的数字。所以我做了一些测试：

1. 我把一个测试目录放在/ home中，大小约为3TB。它是整个/主目录的部分副本，具有典型的文档，文本文件，图像和程序组合
2. 我使用.tar.gz压缩了这个目录，导致文件大小

# du -s ./test.tar.gz
1672083116      ./test.tar.gz

3. 使用此文件存在于文件系统中，我执行了以下操作：

# du -s /home
11017624664     /home

# du --apparent-size -s /home
11010709168     /home

# df /home
Filesystem       1K-blocks       Used   Available Use% Mounted on
/dev/md2       31230406656 9128594488 22095200200  30% /home

这意味着我们有((11017624664/(1024**2))/(9128594488/(1024**2))-1)*100 = 20%压缩比

4. 然后我删除了这个文件，我得到了这个：

# du -s /home
9348284812    /home

# du --apparent-size -s /home
9340957158     /home

# df /home
Filesystem       1K-blocks       Used   Available Use% Mounted on
/dev/md2       31230406656 7455549036 23764949364  24% /home

产生25％的压缩比。同样根据这些信息，我得出结论，在磁盘1595 G上占用了实际大小为1592 G的test.tar.gz文件。另外我注意到使用--apparent-size标志会产生微不足道的差异，可能是由于块大小的舍入。

旁注，我用于安装此分区的fstab行是：

UUID=be6...07fe /home btrfs defaults,compress=zlib 0 2

Summary:

要检查整个分区的压缩率，请使用以下两个命令：

du -s /home
df /home

然后划分输出。我想我的25％压缩比是zlib压缩器的典型结果。

Answer 5

您可以在文件中创建Btrfs文件系统，安装它，在那里复制文件并运行df：

$ dd if=/dev/zero of=btrfs.data size=1M count=1K
$ mkdir btrfs
$ mount btrfs.data btrfs -o compress
... copy the files to ./btrfs
$ sync
$ cd btrfs
$ btrfs filesystem df .

从17MiB压缩到5MiB的单个文件示例：

$ cd btrfs
$ ls -l
-rwx------ 1 atom atom 17812968 Oct 27  2015 commands.bin
$ btrfs filesystem df .
Data, single: total=1.01GiB, used=5.08MiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B

Answer 6

在Ubuntu-18上

apt install btrfs-compsize
compsize /mnt/btrfs-partition

Answer 7

运行btrfs filesystem df /mountpoint。

示例输出：

Data: total=2.01GB, used=1.03GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.00GB, used=2.52MB
Metadata: total=8.00MB, used=0.00

关键线从Data:开始; used=是压缩大小，total=是总大小，就像在未压缩的文件系统上一样。我创建了一个测试文件系统，使用compress_force=zlib选项安装它，并将1GB的零复制到文件系统上的文件中;那时Data:线是Data: total=1.01GB, used=32.53MB（零是可压缩的！）。然后我重新安装了禁用压缩的文件系统，将另一个GB的零复制到它，然后Data:行读取Data: total=2.01GB, used=1.03GB。

正如上面提到的nemequ，相反，ls -l显示了未压缩的尺寸。