我注意到这两个列出 5 GiB 以下文件的命令产生了不同的结果：
find . -type f -size -5368709120c
find . -type f -size -5G
具体来说，使用千字节单位（5368709120c）的函数返回的附加文件大小大于使用 GiB 单位（5G）的函数返回的最大文件大小。
我从find手册页中读到以下内容：
-size n[cwbkMG]
File uses n units of space. The following suffixes can be used:
`b' for 512-byte blocks (this is the default if no suffix is used)
`c' for bytes
`w' for two-byte words
`k' for Kilobytes (units of 1024 bytes)
`M' for Megabytes (units of 1048576 bytes)
`G' for Gigabytes (units of 1073741824 bytes)
The size does not count indirect blocks, but it does count blocks
in sparse files that are not actually allocated. Bear in mind that the `%k'
and `%b' format specifiers of -printf handle sparse files differently. The
`b' suffix always denotes 512-byte blocks and never 1 Kilobyte blocks,
which is different to the behaviour of -ls.
因此，假设的单位G是 1073741824，则5G应该是5368709120c。问题是由于如何计算稀疏块或间接块造成的？
先谢谢您的帮助。
** 更新 **
发现了其他奇怪的东西。返回文件不同的阈值恰好是 4 GiB：
找到的最大文件-5G：
4285018593 bytes = 3.990734548 GiB
最大不是文件找到者-5G：
4299230968 bytes = 4.003970854 GiB
文件存储在XFS分区上：
meta-data=/dev/mapper/vg_XXXXX_lv isize=256 agcount=197, agsize=268435440 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=52739701760, imaxpct=1
= sunit=16 swidth=256 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
答案1
参见超级用户的回答卡米尔