Por que não há diretório lost + found no pool de armazenamento?

0

Estou estudando este canal vermelho Documentação do Hat , que declara que um pool de armazenamento validado deve ter um diretório lost+found para indicar que está corretamente montado.

Eu segui as instruções da documentação explicitamente, mas ainda assim meus resultados (mostrados abaixo) não incluem um diretório lost+found .

Este pool de armazenamento foi montado corretamente? O que mais precisa ser feito para que o pool de armazenamento descrito abaixo seja validado corretamente? Caso contrário, se o abaixo for validado como montado corretamente, explique as razões subjacentes.

Crie e inicie / inicie automaticamente o pool de armazenamento:
[root@remote-host ~]# virsh pool-define-as eighthPool fs - - /dev/mapper/centos-eighth - "/eighthPool"
Pool eighthPool defined

[root@remote-host ~]# virsh pool-build eighthPool
Pool eighthPool built

[root@remote-host ~]# virsh pool-start eighthPool
Pool eighthPool started

[root@remote-host ~]# virsh pool-autostart eighthPool
Pool eighthPool marked as autostarted

Validar o pool de armazenamento:
[root@remote-host ~]# virsh pool-list --all
 Name                 State      Autostart
-------------------------------------------
 eighthPool           active     yes
 home                 active     yes
 root                 active     yes
 someUserName         active     yes
 tmp                  active     yes

[root@remote-host ~]# virsh pool-info eighthPool
Name:           eighthPool
UUID:           230c3939-b009-4d28-97ff-09419492cd9b
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       224.89 GiB
Allocation:     32.20 MiB
Available:      224.85 GiB

[root@remote-host ~]# mount | grep /eighthPool
/dev/mapper/centos-eighth on /eighthPool type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

[root@remote-host ~]# ls -la /eighthPool
total 4
drwxr-xr-x.  2 root root    6 Mar 12 11:03 .
dr-xr-xr-x. 25 root root 4096 Mar 20 08:23 ..
[root@remote-host ~]#

Outros conteúdos do disco físico:

Para referência, as partições do disco rígido antes de criar o novo conjunto de armazenamento são listadas da seguinte forma:

[root@remote-host ~]# fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt

#         Start          End    Size  Type            Name
 1         2048       411647    200M  EFI System      EFI System Partition
 2       411648      1435647    500M  Microsoft basic
 3      1435648   3897165823    1.8T  Linux LVM

Disk /dev/mapper/centos-root: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/centos-swap: 8187 MB, 8187281408 bytes, 15990784 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/centos-home: 241.6 GB, 241591910400 bytes, 471859200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

....Other extraneous stuff omitted for brevity.

Disk /dev/mapper/centos-eighth: 241.6 GB, 241587716096 bytes, 471851008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    
por CodeMed 20.03.2017 / 16:45

1 resposta

2

lost + found é um diretório normalmente criado quando um ponto de montagem é formatado com um sistema de arquivos padrão do Linux, como ext. Eu não joguei muito com o XFS, mas o afaik lost + found é específico da ferramenta fsck e o XFS não o usa, então eu suponho que o XFS também não pode usar o diretório.

Em qualquer caso, a existência de lost + found (que você pode reconstruir normalmente usando mklost+found ) não é realmente indicativa de uma integridade do pool de armazenamento libvirt. Ele funcionará enquanto libvirt e qemu tiverem acesso rw ao ponto de montagem.

    
por 20.03.2017 / 21:41