Noté que estos dos comandos para enumerar archivos por debajo de 5 GiB producen resultados diferentes:
find . -type f -size -5368709120c
find . -type f -size -5G
Específicamente, el que usa la unidad kilobyte ( 5368709120c) devuelve archivos adicionales que son más grandes que el tamaño máximo de archivo devuelto por el que usa la unidad GiB ( 5G).
De la findpágina del manual leí lo siguiente:
-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.
Entonces, dado que la unidad de Ges 1073741824, 5Gdebería ser 5368709120c. ¿El problema se debe a qué tan escasos o indirectos se cuentan los bloques?
Gracias de antemano por la ayuda.
** ACTUALIZAR **
Encontré algo más extraño. El umbral en el que los archivos devueltos son diferentes es exactamente 4 GiB:
Archivo más grande encontrado por -5G:
4285018593 bytes = 3.990734548 GiB
más grandenoarchivo encontrado por -5G:
4299230968 bytes = 4.003970854 GiB
Los archivos se almacenan en una partición 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
Respuesta1
Ver respuesta en Superusuario porKamil