これは私を混乱させます。これは簡単だと思いましたが、結果が一貫していないため、何かが欠けているようです。
私は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,586kBです。
dfは、合計1,922,858,380個の1kブロック（128,206個の差）= 480,714,595個の4kブロックを示しています。
それにもかかわらず、最終結果は、実際にファイルをコピーしたときにawk出力によって報告された「残りのスペース」が実際の残りのスペースと同じではないことです。下の画像を始点として使用しても、次のようになります。数量が異なります、時にはスペースが完全に不足している場合があります。
私のロジックに何の問題がありますか？ MAXSIZEを減らしてパージできることを知っていますが、私が何を見逃しているのか本当に知りたいです！
PS私はこれをrootとして実行しているので、予約されたスペースは関係ありません。
実際の質問を明確にするために、ファイルとディレクトリのサイズ（合計4kブロック）を合計して合計ディスク使用量を取得できる必要がありますか？
追加編集：さらに混乱させるために、ドライブをいっぱいにし（？）、df -kからこれを得ました。
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdzb1 2927209048 2925317912 0 100% /share/external/sdzb1
2927209048-2925317912=1891136 学生時代に使ったのと同じですね！
ベストアンサー1
2つの観察：
ファイルが使用するブロック数を減らすのではなく、丸める必要があります。ファイル長が8192 + 1バイトの場合、最後のバイトに4KiBブロックが割り当てられます。 （「彫刻サイズ」が4KiBだからです。）
ファイルに必要なディスク・スペースは、ファイルのバイト数を保持するのに必要なデータ・ブロックの数と必ずしも同じではありません。これは少し大きくすることができます（割り当てられたブロックをマップするためにより多くのメタデータを必要とする大きなファイルの場合）、少し小さくすることができます（inodeに完全に保存できる非常に小さいファイルの場合）。また、Stephen Kittユーザーが述べたように、全体の質問は次のとおりです。スパースファイルこれは、ディスクが占めるスペースよりはるかに大きくなる可能性があり、他のファイルシステムにアーカイブまたはコピーすると興味深い問題を引き起こす可能性があります。
一部のファイルシステムでは、独自の目的でいくつかのディスク領域を使用できます。また、使用されているディスク容量が容量に近づくと、ファイルシステムが失敗する傾向があります。実際にディスクを98％または99％以下でいっぱいにする計画を立てる必要があります。