web-dev-qa-db-ja.com

LVMは私のディスク容量を消費しますか、それともdfは嘘をつきますか？

以下の出力を見てください：

bob ~ # df -h
Filesystem                 Size  Used Avail Use% Mounted on
udev                       5,7G  4,0K  5,7G   1% /dev
tmpfs                      1,2G  1,5M  1,2G   1% /run
/dev/mapper/mint--vg-root  218G   66G  142G  32% /
none                       4,0K     0  4,0K   0% /sys/fs/cgroup
tmpfs                      5,7G  528M  5,2G  10% /tmp
none                       5,0M     0  5,0M   0% /run/lock
none                       5,7G   99M  5,6G   2% /run/shm
none                       100M   48K  100M   1% /run/user
tmpfs                      5,7G   44K  5,7G   1% /var/tmp
/dev/sda1                  236M  132M   93M  59% /boot

dfは、LVMパーティションが218Gであるのに対し、250Gである必要があることを報告しています。1024で再計算する場合は、232Gです。14Gはどこにありますか？しかし、218-66 = 152でさえ142ではありません！それはまたどこにもない10ギガバイトですか？

その他のutils出力：

bob ~ # pvs
  PV         VG      Fmt  Attr PSize   PFree
  /dev/sda5  mint-vg lvm2 a--  232,64g    0 

bob ~ # pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               mint-vg
  PV Size               232,65 GiB / not usable 2,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              59557
  Free PE               0
  Allocated PE          59557
  PV UUID               3FA5KG-Dtp4-Kfyf-STAZ-K6Qe-ojkB-Tagr83

bob ~ # fdisk -l /dev/sda

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00097b2a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          501758   488396799   243947521    5  Extended
/dev/sda5          501760   488396799   243947520   8e  Linux LVM

# sfdisk -l -uM

Disk /dev/sda: 30401 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start   End    MiB    #blocks   Id  System
/dev/sda1   *     1    243    243     248832   83  Linux
/dev/sda2       244+ 238474  238231- 243947521    5  Extended
/dev/sda3         0      -      0          0    0  Empty
/dev/sda4         0      -      0          0    0  Empty
/dev/sda5       245  238474  238230  243947520   8e  Linux LVM

Disk /dev/mapper/mint--vg-root: 30369 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/mapper/mint--vg-root: unrecognized partition table type
No partitions found

Linux Mint 17.3

[〜＃〜]更新[〜＃〜]

# lvdisplay
  --- Logical volume ---
  LV Path                /dev/mint-vg/root
  LV Name                root
  VG Name                mint-vg
  LV UUID                ew9fDY-oykM-Nekj-icXn-FQ1T-fiaC-0Jw2v6
  LV Write Access        read/write
  LV Creation Host, time mint, 2016-02-18 14:52:15 +0200
  LV Status              available
  # open                 1
  LV Size                232,64 GiB
  Current LE             59557
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

スワップについて。当初はLVMにありました。次に、それを削除し、スワップで使用されたスペース（約12G）でルートパーティションを拡張しました。

PDATE2

# tune2fs -l /dev/mapper/mint--vg-root
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          0b5ecf9b-a763-4371-b4e7-01c36c47b5cc
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:              14491648
Block count:              57952256
Reserved block count:     2897612
Free blocks:              40041861
Free inodes:              13997980
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1010
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Thu Feb 18 14:52:49 2016
Last mount time:          Sun Mar 13 16:49:48 2016
Last write time:          Sun Mar 13 16:49:48 2016
Mount count:              22
Maximum mount count:      -1
Last checked:             Thu Feb 18 14:52:49 2016
Check interval:           0 (<none>)
Lifetime writes:          774 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:       6160636
Default directory hash:   half_md4
Directory Hash Seed:      51743315-0555-474b-8a5a-bbf470e3ca9f
Journal backup:           inode blocks

PDATE3（最終）

Jonasのおかげで、スペースの損失が見つかりました

# df -h
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/mint--vg-root  218G   65G  142G  32% /


# resize2fs /dev/mapper/mint--vg-root
resize2fs 1.42.9 (4-Feb-2014)
Filesystem at /dev/mapper/mint--vg-root is mounted on /; on-line resizing required
old_desc_blocks = 14, new_desc_blocks = 15
The filesystem on /dev/mapper/mint--vg-root is now 60986368 blocks long.

# df -h
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/mint--vg-root  229G   65G  153G  30% /

これは、resize2fsの実行前後のtune2fsコマンド出力の差分です。

# diff /tmp/tune2fs_before_resize2fs /tmp/tune2fs2_after_resize2fs
13,17c13,17
< Inode count:              14491648
< Block count:              57952256
< Reserved block count:     2897612
< Free blocks:              40041861
< Free inodes:              13997980
---
> Inode count:              15253504
> Block count:              60986368
> Reserved block count:     3018400
> Free blocks:              43028171
> Free inodes:              14759836
21c21
< Reserved GDT blocks:      1010
---
> Reserved GDT blocks:      1009
38c38
< Inode size:           256
---
> Inode size:             256
42c42
< First Orphan inode:       6160636
---
> First Orphan inode:       5904187
linuxdisk-usagelvm
2
gumkins

いくつかの調査をしましょう。私は以前にその違いに気づきましたが、損失の原因を詳細に確認したことはありません。比較のために私のシナリオを見てください：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 -lを呼び出すと、extファミリファイルシステムに関する多くの興味深い情報が出力され、次のようになります。

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（これも出力から）を掛けると、df Used + AvailとSizeの差が得られます。

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

特にdfの丸めを考慮して十分に近い（-hなしでdfを使用し、計算を繰り返すと、Used + AvailとSizeの違いが説明できない16 MiBのままになる）。予約済みブロックの予約先もtune2fs出力に書き込まれます。根です。 これは、root以外のユーザーがディスクをいっぱいにすることによってシステムを完全に使用不可にすることができず、ディスク領域の数パーセントを未使用にしておくことも断片化の防止に役立つセーフティネットです。

次に、dfによって報告されるサイズとパーティションのサイズの違いについて説明します。これは、iノードを見ると説明できます。 ext4はiノードを事前に割り当てるため、ファイルデータにスペースを使用できません。 Inode countにInode sizeを掛けると、次のようになります。

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

Iノードは基本的にディレクトリエントリです。詳細についてmkfs.ext4に聞いてみましょう（man mkfs.ext4から）：

-i bytes-per-inode

バイト数とiノードの比率を指定します。 mke2fsは、ディスク上のbytes-per-inodeバイトのスペースごとにiノードを作成します。 bytes-per-inode比が大きいほど、作成されるiノードの数は少なくなります。通常、この値はファイルシステムのブロックサイズより小さくすべきではありません。その場合、これまで使用できるよりも多くのiノードが作成されるからです。ファイルシステムの作成後にこの比率を変更することはできないことに注意してください。したがって、このパラメーターの正しい値を慎重に決定してください。ファイルシステムのサイズを変更すると、この比率を維持するためにiノードの数が変更されることに注意してください。

さまざまなシナリオで使用するさまざまなプリセットがあります。 Linuxディストリビューションイメージがたくさんあるファイルサーバーでは、たとえば、 -T largefileまたは-T largefile4。 -Tの意味は、これらの例と私のシステムの/etc/mke2fs.confで定義されています。

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

したがって、-T largefile4を使用すると、の数はデフォルトよりはるかに少なくなります（私の/etc/mke2fs.confのデフォルトの比率は16384です）。つまり、ディレクトリエントリ用に予約されているスペースが少なくなり、データ用のスペースが増えます。 iノードが不足すると、新しいファイルを作成できなくなります。既存のファイルシステムのiノードの数を増やす 可能ではないようです 。したがって、平均的なユーザーがiノードを時期尚早に使い果たしないように、デフォルトのiノード数はかなり控えめに選択されています。

私は自分の番号を突っついたときにそれがわかったので、それがあなたにとってうまくいくかどうか（知らない場合）に知らせてください☺.

4
Jonas Schäfer

確認しやすい場所は、論理ボリューム（物理ボリュームほど大きくする必要はありません）です。サイズを確認するには、lvdisplayを使用します。

そこに違いが見られない場合、通常の説明では、rootが使用するために予約されているスペースがあり、通常のユーザーはdfに表示しません。

参考文献：

0
Thomas Dickey