我注意到列出小於 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
請參閱超級用戶的答案卡米爾