5GiB 미만의 파일을 나열하는 이 두 명령은 서로 다른 결과를 생성하는 것으로 나타났습니다.
find . -type f -size -5368709120c
find . -type f -size -5G
특히 킬로바이트 단위( )를 사용하는 파일은 5368709120cGiB 단위( 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.
따라서 단위가 G1073741824라는 점을 고려 5G하면 5368709120c. 희박하거나 간접적인 블록이 계산되는 방식으로 인해 문제가 발생합니까?
도움을 주셔서 미리 감사드립니다.
** 업데이트 **
또 이상한 점을 발견했습니다. 반환된 파일이 달라지는 임계값은 정확히 4GiB입니다.
다음에서 찾은 가장 큰 파일 -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
슈퍼 유저에 대한 답변 보기카밀