Правильно ли предсказываете объем использования диска с помощью find / ls / stat и df?

Я пытаюсь программно рассчитать количество файлов, которые могут поместиться на диске. Привод использует LUKS / ext4 и имеет размер блока 4096. Ниже представлена ​​распечатка привода в формате df.

Filesystem                       1K-blocks  Used       Available Use% Mounted on
/dev/mapper/vg_server-lv_storage 7260987808 6258809672 633341120 91% /storage

Проблема, с которой я сталкиваюсь, - это найти команду, которая точно вычисляет пространство, которое файл занимает на этом диске. Например:

[root@server ~]# ls -l test.t
-rw-r--r-- 1 root root 2 May 27 11:34 test.t

[root@server ~]# ls -l test2.t
-rw-r--r-- 1 root root 6301 Jul 18  2011 test2.t

«ls» сообщает 2 байта и 6301 байт.

[root@server ~]# stat test.t
  File: `test.t'
  Size: 2               Blocks: 8          IO Block: 4096   regular file
Device: fd03h/64771d    Inode: 20185186    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-05-27 11:34:55.244368861 -0400
Modify: 2013-05-27 11:34:47.560446365 -0400
Change: 2013-05-27 11:34:47.654445417 -0400

[root@server ~]# stat test2.t
  File: `test2.t'
  Size: 6301            Blocks: 16         IO Block: 4096   regular file
Device: fd05h/64773d    Inode: 177345663   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-05-27 11:06:28.363664283 -0400
Modify: 2011-07-18 16:18:56.000000000 -0400
Change: 2013-05-12 17:05:09.968897077 -0400

"stat" сообщает о 8 используемых блоках (с шагом 512, поэтому 8 * 512 = 4096) и 16 блоках (8192).

[root@server ~]# find . -xdev -printf '%p %k %b\n' |grep test.t
./test.t 4 8

[root@server ~]# find . -xdev -printf '%p %k %b\n' |grep test2.t
./test2.t 8 16

«find» сообщает о блоках 4K / 8 (также с шагом 512, т. е. 4096) и блоках 8K / 16. Все идет нормально.

«df», команда, которую я использую для определения доступных блоков размером 1 КБ (7260987808 выше), сообщает другое число для второго теста.

[root@server ~]# /bin/df -P |grep lv_storage; cp /root/test.t /storage/ttt.txt;/bin/df -P |grep lv_storage; rm /storage/ttt.txt; /bin/df -P |grep lv_storage;
/dev/mapper/vg_server-lv_storage 7260987808 6258809672 633341120      91% /storage
/dev/mapper/vg_server-lv_storage 7260987808 6258809680 633341112      91% /storage
/dev/mapper/vg_server-lv_storage 7260987808 6258809672 633341120      91% /storage

[root@server ~]# /bin/df -P |grep lv_storage; cp /root/test2.t /storage/ttt.txt;/bin/df -P |grep lv_storage; rm /storage/ttt.txt; /bin/df -P |grep lv_storage;
/dev/mapper/vg_server-lv_storage 7260987808 6258809672 633341120      91% /storage
/dev/mapper/vg_server-lv_storage 7260987808 6258809684 633341108      91% /storage
/dev/mapper/vg_server-lv_storage 7260987808 6258809672 633341120      91% /storage

Это показывает 633341120-633341112 = 8 для первого файла.

Затем для первого файла отображается 633341120-633341108 = 12. НЕПРАВИЛЬНО. Должно быть 16.

Я думал, что это просто проблема с df, возможно, какой-то резерв безопасности, чтобы люди не заполняли диски, но когда я подсчитал количество файлов, которые могут поместиться на диске, используя find% k, а затем вычел некоторые отступы, чтобы быть в безопасности, это переполнение диска и ошибка rsync.

Для справки,% k определяется как:

          %k     The amount of disk space used for this file in 1K blocks. Since disk space is allocated in multiples of the filesystem block size this is usually greater than %s/1024, but it can also be
                 smaller if the file is a sparse file.

Любые идеи?