LVMは私のディスク容量を占めていますか、それともdfが嘘をついていますか？

Question 1

ちょっと調べてみましょう。私は以前この違いを見つけましたが、損失の原因が何であるかを詳しく調べたことがありません。比較のために私のシナリオを見てください。 fdisk は次のパーティションを示しています。

/dev/sda3       35657728 1000214527 964556800  460G 83 Linux

私のファイルシステムはluksコンテナにあるので、いくつかの損失がありますが、これはほんの数MiBです。 dfは以下を示しています：

Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-1       453G  373G   58G  87% /

（luksコンテナは/dev/sda3が/dev/dm-1と一致しない理由ですが、実際には暗号化が途中でLVMがない同じデバイスです。これもLVMがあなたの問題に対して責任を負いません）示しています。

それでは、ファイルシステム自体について質問しましょう。とすると、tune2fs -lextシリーズファイルシステムに関する多くの興味深い情報が出力されます。

root@altair ~ › tune2fs -l /dev/dm-1
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          0de04278-5eb0-44b1-9258-e4d7cd978768
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index 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:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30146560
Block count:              120569088
Reserved block count:     6028454
Free blocks:              23349192
Free inodes:              28532579
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      995
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Oct 14 09:27:52 2015
Last mount time:          Sun Mar 13 12:25:50 2016
Last write time:          Sun Mar 13 12:25:48 2016
Mount count:              23
Maximum mount count:      -1
Last checked:             Wed Oct 14 09:27:52 2015
Check interval:           0 (<none>)
Lifetime writes:          1426 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       26747912
Default directory hash:   half_md4
Directory Hash Seed:      4723240b-9056-4f5f-8de2-d8536e35d183
Journal backup:           inode blocks

一目で私の目をひきつけたのはおそらくReserved blocks。これをBlock size（出力でも）乗算すると、dfUsed + AvailとSizeの違いが得られます。

453GiB - (373GiB+58GiB) = 22 GiB
6028454*4096 Bytes = 24692547584 Bytes ~= 23 GiB

特にdfラウンドを考慮すると十分に近いです（-hなしでdfを使用して計算を繰り返すと説明できないUse + AvailとSizeの差は16MiBしか残りません）。予約済みブロックの予約済みオブジェクトは、tune2fs出力にも書き込まれます。ルートです。これは、root以外のユーザーがディスクをいっぱいにしてシステムを完全に使用できなくするのを防ぎ、ディスクスペースの数パーセントを使用しないようにすることも断片化を防ぐのに役立つ安全ネットワークです。

次に、dfが報告したサイズとパーティションサイズの違いを見てみましょう。これはインデックスノードを見ることで説明できます。 ext4 はファイルデータにスペースを使用できないように inode を事前に割り当てます。Inode countこれを掛けると、次Inode sizeのような結果が得られます。

30146560*256 Bytes = 7717519360 Bytes ~= 7 GiB
453 GiB + 7 GiB = 460 GiB

Inodeはデフォルトでディレクトリエントリです。詳細については、mkfs.ext4にお問い合わせください（man mkfs.ext4から）。

-私bytes-per-inode

バイト/アノード比を指定します。 mke2fs は、 bytes-per-inode ディスク領域のすべてのバイトに対して inode を生成します。比率が大きいほど、 bytes-per-inode 少ない inode が生成されます。この値は通常、ファイルシステムのブロックサイズより小さくしてはいけません。これは、利用可能なものよりも多くのinodeが生成されるためです。ファイルシステムが作成された後は、この比率を変更することはできません。注意して、このパラメータの正しい値を決定してください。ファイルシステムのサイズを変更すると、この割合を維持するためにinodeの数が変更されます。

さまざまなシナリオに使用できるさまざまなプリセットがあります。多数のLinuxディストリビューションイメージを持つファイルサーバーでたとえば-T largefileevenを渡すと、-T largefile4次の例と私のシステムで意味が定義されます-T。/etc/mke2fs.conf

largefile = {
    inode_ratio = 1048576
}
largefile4 = {
    inode_ratio = 4194304
}

したがって、-T largefile4数字はデフォルト値よりはるかに小さいです（デフォルトの比率は16384です/etc/mke2fs.conf）。これは、ディレクトリエントリに少ないスペースが予約され、データに多くのスペースが予約されることを意味します。 inodeが足りないと、新しいファイルを作成できません。既存のファイルシステムのinode数を増やす不可能に見える。したがって、デフォルトのinode番号は、通常のユーザーのinodeが早期に不足しないように、かなり保守的に選択されます。

ただ私の電話番号を見て、これを見つけました。うまくいかなかったら教えてください☺。

Answer