確定排序列表中有多少文件將填滿磁碟
這讓我很困惑。我認為這應該很容易，但我必須遺漏一些東西，因為結果並不一致。
我正在將一長串文件備份到多個磁碟，使用 rsync，使用按時間順序排序的列表，這樣最早的文件放在第一個磁碟上，後面的文件放在第二個磁碟上，依此類推。
我瀏覽了以 4k 塊為單位添加文件大小的列表，並記下最後一個適合的文件的日期。然後我創建一個列表，使用“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}並使用“–files-from”將其提供給 rsync 以實際進行複制。
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 字節的 inode。因此應該有 (488378007 x 4096) - (122101760 x 256) 字節可供寫入。即 1,969,138,264,064，即 1,922,986,586 kB。
df 顯示總共 1,922,858,380 個 1k 塊，（128,206 個差異），= 480,714,595 個 4k 塊。
無視這一點，最終結果是，當我實際複製文件時，即使使用較低的數字作為起點，從 awk 輸出報告的“剩餘空間”也不等於實際剩餘空間，有時會有不同的數量甚至完全耗盡空間。
我的邏輯哪裡出錯了？我知道我可以通過減小 MAXSIZE 來偽造它，但我真的很想了解我缺少什麼！
附言。我以 root 身份執行它，因此保留空間無關緊要。
只是為了澄清實際問題：我是否應該能夠將文件和目錄大小（整個 4k 塊）相加以獲得總磁碟使用量？
附加編輯：只是為了進一步混淆我剛剛填滿（？）一個驅動器並從 df -k 得到這個：
Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdzb1 2927209048 2925317912 0 100% /share/external/sdzb12927209048-2925317912=1891136，還是上學的時候用的！
兩個觀察：
- 您需要將文件使用的塊數向上取整，而不是向下取整；如果文件長度為 8192+1 個字節，則最後一個字節將分配一個 4 KiB 塊。（因為“片段大小”是 4 KiB。）
- 文件所需的磁碟空間不一定等於保存文件中字節數所需的數據塊數。它可以稍微大一點（對於需要更多元數據來映射其分配塊的較大文件），或者更小（對於可以完全儲存在其 inode 中的非常小的文件）。另外，正如使用者 Stephen Kitt 所提到的，存在*稀疏文件*的整個問題，其大小可能比它們在磁碟上佔用的空間大得多，並且在存檔或複製到不同的文件系統時可能會導致有趣的問題。
- 一些文件系統可能會出於自己的目的使用一些磁碟空間。此外，當使用的磁碟空間接近容量時，文件系統往往會出現異常。您確實應該計劃將磁碟填充不超過 98% 或 99%。