Debian系统中du -sh与Samba显示文件夹复制后大小不一致的原因咨询

这个问题其实挺常见的，核心原因是Linux的du命令和Windows/Samba的大小统计逻辑完全不同，咱们拆解几个最可能的情况：

1. 磁盘块大小与实际文件字节数的差异 #

du -sh统计的是文件实际占用的磁盘块空间，而不是文件的原始字节大小。举个例子：如果你的源文件夹在ext4文件系统上（默认块大小4KB），里面有1000个1KB的小文件，每个文件都会占用1个4KB的块，du会统计出1000*4KB=4GB的占用量；但这些文件的实际总字节数只有1GB。

而Windows通过Samba挂载后，默认显示的是文件的原始字节大小（也就是1GB），不是磁盘块占用量。如果目标文件夹所在的文件系统块更小（比如2KB），那同样1000个1KB文件只会占用2GB的磁盘空间，du显示目标文件夹为2GB，但Windows看到的原始字节数还是1GB，所以两边显示一致。

2. 文件系统压缩的影响 #

如果目标文件夹所在的文件系统启用了透明压缩（比如btrfs、ZFS的压缩功能），复制过去的文件会被自动压缩，du统计的是压缩后的实际磁盘占用空间（也就是你看到的384G），而源文件夹的文件是未压缩的，du显示436G。

但Windows通过Samba访问时，看到的是文件解压后的原始大小，所以源和目标的显示大小是一致的——毕竟文件内容没变化，只是存储时被压缩了。

3. 稀疏文件的统计差异 #

稀疏文件是一种特殊文件，里面包含“空洞”（即未写入数据的区域），磁盘上实际不会存储这些空洞的内容。du默认会忽略空洞，只统计实际写入的数据占用的空间；而Windows/Samba会显示文件的逻辑大小（包括空洞的字节数）。

比如一个逻辑大小100G的稀疏文件，实际只占用10G磁盘空间，du会显示10G，但Windows会显示100G。如果复制时保留了稀疏属性，目标文件夹的du也会显示10G，Windows显示100G，这就会出现du数值不同但Windows显示一致的情况。

4. 符号链接的特殊处理 #

du默认不会跟随符号链接，只会统计符号链接本身的大小（通常只有几字节）。如果源文件夹里有大量指向外部大文件的符号链接，且你不小心用了du -Lsh（强制跟随符号链接）统计源文件夹，那du会把链接指向的文件大小也算进去，导致源的数值偏大；而如果复制时没有复制这些符号链接，目标文件夹的du就会小很多，但Windows看不到这些符号链接指向的外部文件，所以显示的大小和源一致。

总结一下：最大概率是磁盘块大小差异或者目标文件系统启用了压缩，导致du统计的实际磁盘占用不同，但Windows看到的是文件原始字节大小，所以显示一致。

内容的提问来源于stack exchange，提问作者user3262987