O LVM consome o espaço em disco ou o df lie?

1

Por favor, olhe a saída abaixo:

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 informa que a partição LVM tem 218G, considerando que deve ser 250G, bem 232G se for recalcular com 1024. Então, onde está 14G? Mas mesmo 218-66 = 152 não 142! Isso é mais 10 Gigabytes que também estão em nenhum lugar?

Saída de outros utilitários:

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

UPDATE

# 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

Em relação ao swap. Inicialmente estava lá, no LVM. Então eu removi e estendi a partição raiz com o espaço que foi usado pelo swap (cerca de 12G)

UPDATE2

# 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

UPDATE3 (final)

Graças a Jonas, a perda de espaço foi encontrada

# 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% /

e este é um diff da saída do comando tune2fs antes e depois do resize2fs em execução

# 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
    
por gumkins 16.03.2016 / 00:25

2 respostas

4

Vamos fazer algumas pesquisas. Eu notei essa diferença antes, mas nunca verifiquei detalhadamente a que atribuir as perdas. Dê uma olhada no meu cenário para comparação: o fdisk mostra a seguinte partição:

/dev/sda3       35657728 1000214527 964556800  460G 83 Linux

Haverá algumas perdas, pois meu sistema de arquivos mora em um container luks, mas isso deve ser de apenas alguns MiB. df mostra:

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

(O container luks é também porque / dev / sda3 não combina com / dev / dm-1, mas eles são realmente o mesmo dispositivo, com criptografia entre eles, sem LVM. Isso também mostra que a LVM não é responsável por suas perdas Eu também tenho eles.)

Agora vamos perguntar ao sistema de arquivos sobre esse assunto. Chamando tune2fs -l , que gera muitas informações interessantes sobre os sistemas de arquivos da família ext, obtemos:

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

Olhando por cima, o primeiro que surge nos seus olhos deve ser Reserved blocks . Multiplicando isso com o Block size (também da saída), obtemos a diferença entre o df Usado + Avail e Size:

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

Perto o suficiente, especialmente considerando que df rounds (usando df sem -h e repetindo o cálculo, deixa apenas 16 MiB da diferença entre Used + Avail e Size inexplicado). A quem os blocos reservados são reservados, também é escrito na saída tune2fs. É a raiz. Esta é uma rede de segurança para garantir que usuários não-root não possam tornar o sistema totalmente inutilizável, preenchendo o disco, e mantendo alguns Porcentagem de espaço em disco não utilizado também ajuda na fragmentação.

Agora, a diferença entre o tamanho informado por df e o tamanho da partição. Isso pode ser explicado dando uma olhada nos inodes. O ext4 pré-aloca inodes, de modo que o espaço é inutilizável para os dados do arquivo. Multiplique o Inode count pelo Inode size e você terá:

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

Os inodes são basicamente entradas de diretório. Vamos perguntar ao mkfs.ext4 sobre detalhes (do man mkfs.ext4):

-i bytes-per-inode

Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value generally shouldn't be smaller than the blocksize of the filesystem, since in that case more inodes would be made than can ever be used. Be warned that it is not possible to change this ratio on a filesystem after it is created, so be careful deciding the correct value for this parameter. Note that resizing a filesystem changes the numer of inodes to maintain this ratio.

Existem predefinições diferentes para usar em diferentes cenários. Num servidor de ficheiros com muitas imagens de distribuição linux, faz sentido passar, e. -T largefile ou mesmo -T largefile4 . O que -T significa está definido em /etc/mke2fs.conf , nesses exemplos e no meu sistema:

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

Portanto, com -T largefile4 , o número de é muito menor que o padrão (a proporção padrão é 16384 no meu /etc/mke2fs.conf ). Isso significa menos espaço reservado para entradas de diretório e mais espaço para dados. Quando você ficar sem inodes, não poderá criar novos arquivos. Aumentar o número de inodes em um sistema de arquivos existente não parece ser possível . Assim, o número padrão de inodes é escolhido de forma conservadora para garantir que o usuário médio não fique sem inodes prematuramente.

Eu só percebi isso em cutucando meus números, deixe-me saber se (não) funciona para você <.

    
por 16.03.2016 / 10:08
0

Um local fácil de verificar seria no volume lógico (que não precisa ser tão grande quanto o volume físico). Use lvdisplay para ver o tamanho.

Se isso não mostrar uma diferença, a explicação usual é que há espaço reservado para uso pelo root, que não é mostrado em df por um usuário normal.

Leitura adicional:

por 16.03.2016 / 02:15