Fedora 25 GNU / Linux - encontre espaço em disco perdido e redimensione o LVM

0

Instalei o Fedora Server 25 de 64 bits usando o LVM e o particionamento de disco automático.
Automaticamente criado / volume de raiz era muito pequeno (16 GB) e muito espaço livre foi deixado e ainda está disponível no disco. O disco é uma unidade SATA de 180 GB da Intel SSD.
Então eu redimensionei / root com o "lvextend" e "pvresize" alocando 100% do espaço livre para ele em um sistema live CD.
Algo deu errado porque o volume / root foi redimensionado (agora tem cerca de 170 GB), mas ainda está 98% cheio.
Por favor, verifique a saída dos comandos "fdisk -l" e "df -h":

[igor@uc-srv ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 3.9G     0  3.9G   0% /dev
tmpfs                    3.9G  256K  3.9G   1% /dev/shm
tmpfs                    3.9G  1.6M  3.9G   1% /run
tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/mapper/fedora-root   15G   15G  406M  98% /
tmpfs                    3.9G   32K  3.9G   1% /tmp
/dev/sda1                976M  138M  772M  16% /boot
/dev/sdb1                341G   52G  289G  16% /media/ntfs1
tmpfs                    793M   16K  793M   1% /run/user/42
tmpfs                    793M   16K  793M   1% /run/user/1000

[igor@uc-srv ~]$ sudo fdisk -l
Disk /dev/sda: 167.7 GiB, 180045766656 bytes, 351651888 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
Disklabel type: dos
Disk identifier: 0xc0948dd2

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   2099199   2097152     1G 83 Linux
/dev/sda2       2099200 351651839 349552640 166.7G 8e Linux LVM


Disk /dev/sdb: 372.6 GiB, 400088457216 bytes, 781422768 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
Disklabel type: dos
Disk identifier: 0xc0c96c56

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1  *         2048 714313727 714311680 340.6G  7 HPFS/NTFS/exFAT
/dev/sdb2       714313728 781420543  67106816    32G  7 HPFS/NTFS/exFAT

Disk /dev/mapper/fedora-root: 158.8 GiB, 170515234816 bytes, 333037568 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 /dev/mapper/fedora-swap: 7.9 GiB, 8451522560 bytes, 16506880 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

Como você pode ver, o df diz que o fedora-root é de 15 GB, o fdisk diz que é de 158 GB. O que devo fazer para recuperar o espaço livre e atribuí-lo corretamente a / root?

UPDATE: quando eu corro:

sudo resize2fs /dev/mapper/fedora-root  

Eu recebo:

resize2fs 1.43.3 (04-Sep-2016)
resize2fs: Bad magic number in super-block while trying to open /dev/mapper/fedora-root
Couldn't find valid filesystem superblock.
    
por Marek 01.07.2017 / 14:04

1 resposta

0

Parece que você executou lvextend sem fornecer a opção -r (ou --resizefs ). Isso significa que você estendeu o volume, mas o sistema de arquivos no topo - ou dentro dele, se preferir - permaneceu o mesmo. É como um monte de bonecas russas.

Felizmente, você pode fazer isso agora. Executar

sudo xfs_growfs /dev/mapper/fedora-root

e isso aumentará essa partição para preencher o tamanho máximo disponível. (Você pode crescer assim enquanto o sistema está rodando.) Note que isto é para o sistema de arquivos padrão do Fedora Server, o XFS. Outras variantes do Fedora ainda usam o EXT4 por padrão; para esses, substitua xfs_growfs por resize2fs . Ambos têm o mesmo comportamento padrão de crescimento do sistema de arquivos para preencher o espaço disponível, que neste caso será o restante do volume lógico.

Isso é relativamente isento de riscos (provavelmente foi feito milhões de vezes sem nenhum incidente), mas como todas as principais operações do sistema de arquivos, é uma boa ideia ter backups de todos os dados importantes primeiro.

    
por 01.07.2017 / 21:00