☰

ソートされたリストからディスクを埋めるファイルの数を決定する

tag-icon • tag-icon bash awk find rsync disk-usage
ソートされたリストからディスクを埋めるファイルの数を決定する

これは私を混乱させます。これは簡単だと思いましたが、結果が一貫していないため、何かが欠けているようです。

私は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％以下でいっぱいにする計画を立てる必要があります。

答え2

私は自分の考えに貢献して指導してくれたすべての人に感謝しながら、自分の質問に答えます。

ディスクに書き込むときにスペースを割り当てる方法は、ファイルのサイズや種類、スパースファイルなどによって異なります。

削除されたファイルのディレクトリは、最初に作成されたときよりも大きくなる可能性があり、このスペースは回復されません。 （ディレクトリを削除して再作成しない限り）、空のディレクトリはスペースを占有します。

Findは、特に要求しない限り、ディレクトリを報告しません。

スペースはブロック全体として書き込まれ、ブロックサイズはディスクごとに異なり、e2fsdumpから読み取ることができます。

「df」は、空き容量よりも使用されているブロックが少ないと報告しても、約98％以降は空き容量がないと報告します。

# df -B4k --sync
Filesystem      4K-blocks       Used Available Use% Mounted on
/dev/sdzb1      731802262  731493169         0 100% /share/external/sdzb1
/dev/sdzc1      731802262  717225328         0 100% /share/external/sdzc1

'du'は 'df'とは異なる使用法を報告します。

# du -B4k -s /share/external/sdzb1 /share/external/sdzc1
731441722       /share/external/sdzb1
717173881       /share/external/sdzc1

それにもかかわらず、利用可能なスペースを使用して初期開始点が可能です。

Space = (Total blocks x blocksize) - (Total inodes x inode size)

そして、かなり正確な結果を得るには、300,000〜500,000のブロックマージンを許可します。 （約1％以内）

関連情報