Определите, сколько файлов из отсортированного списка заполнит диск.

Это меня озадачило. Я думаю, это должно быть легко, но я, должно быть, чего-то упускаю, так как результаты не совпадают.

Я выполняю резервное копирование длинного списка файлов на несколько дисков с помощью rsync, используя список, отсортированный в хронологическом порядке, так что самые ранние файлы помещаются на 1-й диск, более поздние - на 2-й и так далее.

Я просматриваю список, складывая размеры файлов блоками по 4 КБ, и отмечаю дату последнего подходящего файла. Затем я создаю список, используя «find -not -newer and -newer»

STARTDATE="-newer /tmp/filedate.1"
ENDDATE="-not -newer /tmp/filedate.2"
find $SRC -type f ${STARTDATE} ${ENDDATE} -printf '%P\n' | sort > ${TEMPFILE}

, и передаю его в rsync, используя «--files-from», чтобы фактически выполнить копирование.

rsync -a --progress --verbose --prune-empty-dirs --files-from=${TEMPFILE} ${SRC} ${TARGET}

Я хочу точно выяснить, где разделить файлы, чтобы диски были заполнены до отказа.

Что у меня есть на данный момент:

#%T is the modification time, @ is seconds, 
#%p is the path less the command line part, and %k is disk usage in 1k blocks
#MAXSIZE is number of 4k blocks available on disk
    find $SRC -printf "%T@\t%p\t%k\n" | sort -n | \
    awk -vMS="$MAXSIZE"  '
      BEGIN { FS = "\t";fnumber = 0 }
      {rtot+=int(($3+3)/4); #edit; changed to ceiling on AlexP's advice
       if (rtot<MS) {final=$2;filesize=rtot;}
       else {
            rtot=int(($3+3)/4); #edit; changed to ceiling on AlexP's advice
            fnumber++;
            printf "touch -r \"%s\" /tmp/filedate.%s\n", final, fnumber | "/bin/sh"
            print "Found point " fnumber ". (" final ") 4096 Blocks:"  filesize " Space Left:" (MS-filesize)*4
            }
      }
    '

Детали диска:

    #tune2fs -l /dev/sdzc1
    tune2fs 1.41.4 (27-Jan-2009)
    Filesystem volume name:   <none>
    Last mounted on:          /share/external/sdzc1
    Filesystem UUID:          f3f2e855-b198-4d47-b76f-6526d16b0820
    Filesystem magic number:  0xEF53
    Filesystem revision #:    1 (dynamic)
    Filesystem features:      has_journal ext_attr resize_inode filetype needs_recovery extent flex_bg sparse_super large_file
huge_file uninit_bg dir_nlink extra_isize
    Filesystem flags:         signed_directory_hash
    Default mount options:    (none)
    Filesystem state:         clean
    Errors behavior:          Continue
    Filesystem OS type:       Linux
    Inode count:              122101760
    Block count:              488378007
    Reserved block count:     0
    Free blocks:              89451
    Free inodes:              122088914
    First block:              0
    Block size:               4096
    Fragment size:            4096
    Reserved GDT blocks:      907
    Blocks per group:         32768
    Fragments per group:      32768
    Inodes per group:         8192
    Inode blocks per group:   512
    Flex block group size:    16
    Filesystem created:       Sun May 11 13:45:08 2014
    Last mount time:          Wed Dec  7 11:44:24 2016
    Last write time:          Wed Dec  7 11:44:24 2016
    Mount count:              68
    Maximum mount count:      28
    Last checked:             Fri Feb 20 02:06:42 2015
    Check interval:           15552000 (6 months)
    Next check after:         Wed Aug 19 02:06:42 2015
    Reserved blocks uid:      0 (user admin)
    Reserved blocks gid:      0 (group administrators)
    First inode:              11
    Inode size:               256
    Required extra isize:     28
    Desired extra isize:      28
    Journal inode:            8
    First orphan inode:       75890825
    Default directory hash:   half_md4
    Directory Hash Seed:      1c7f838c-8614-4af0-8506-cd3659e1e5ac
    Directory Magic Number:   0x514E4150
    Journal backup:           inode blocks

Итак, по моему мнению, имеется 488378007 блоков по 4096 байтов и 122101760 инодов по 256 байтов. Следовательно, для записи должно быть доступно (488378007 x 4096) - (122101760 x 256) байтов. то есть 1969 138 264 064, что составляет 1 922 986 586 КБ.

df показывает всего 1 922 858 380 блоков по 1 тыс., (Разница 128 206), = 480 714 595 блоков по 4 тыс.

Не обращая внимания на это, конечный результат состоит в том, что когда я фактически копирую файлы, даже используя нижний рисунок в качестве начальной точки, «оставшееся пространство», сообщаемое в выводе awk, не равно фактическому оставшемуся пространству, на разное количество , иногда даже полное исчерпание свободного места.

Где я ошибся с логикой? Я знаю, что могу обмануть это, просто уменьшив MAXSIZE, но мне действительно хотелось бы понять, чего мне не хватает!

пс. Я использую это как root, поэтому зарезервированное пространство не имеет значения.

Просто чтобы прояснить реальный вопрос: могу ли я суммировать размеры файлов и каталогов (в целых блоках по 4 КБ), чтобы получить общее использование диска?

Дополнительное редактирование: чтобы еще больше запутать, я только что заполнил (?) диск, и я получаю это от df -k:

Filesystem      1K-blocks       Used Available Use% Mounted on
/dev/sdzb1     2927209048 2925317912         0 100% /share/external/sdzb1

2927209048-2925317912 = 1891136, или когда я учился в школе!