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 출력에도 기록됩니다. 루트입니다.이는 루트가 아닌 사용자가 디스크를 채워 시스템을 완전히 사용할 수 없게 만드는 것을 방지하고 디스크 공간의 몇 퍼센트를 사용하지 않도록 유지하는 것도 조각화를 방지하는 데 도움이 되는 안전망입니다.

이제 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