O sistema de arquivos XFS recém-criado mostra 78 GB usados

18

Temos uma matriz de 12 TB RAID 6 que deve ser configurada como uma única partição com um sistema de arquivos XFS . Ao criar o novo sistema de arquivos, ele diz que tem 78 GB em uso, mas não há arquivos na unidade.

[root@i00a ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         32G     0   32G   0% /dev
tmpfs            32G     0   32G   0% /dev/shm
tmpfs            32G   11M   32G   1% /run
tmpfs            32G     0   32G   0% /sys/fs/cgroup
/dev/sdb3       154G  3.9G  150G   3% /
/dev/sdb2      1014M  153M  862M  16% /boot
/dev/sdb1       599M  6.7M  593M   2% /boot/efi
/dev/sdc1       187G  1.6G  185G   1% /var
tmpfs           6.3G     0  6.3G   0% /run/user/0
/dev/sda1        11T   78G   11T   1% /export/libvirt

Fiz algo de errado? Isso é intencional?

Parece que o log do sistema de arquivos ocupa apenas cerca de 2 GB e não consigo descobrir o que mais poderia estar usando o espaço.

[root@i00a ~]# xfs_info /export/libvirt/
meta-data=/dev/sda1              isize=512    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=2929458688, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Informações da partição:

[root@irb00a ~]# parted /dev/sda1
GNU Parted 3.2
Using /dev/sda1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Unknown (unknown)
Disk /dev/sda1: 12.0TB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system  Flags
 1      0.00B  12.0TB  12.0TB  xfs

Este é um Dell FX2 com quatro nós de computação FC430 e dois nós de armazenamento FD332, executando o Red Hat Enterprise Linux 8 ( Ootpa ).

yakatz
fonte
Está realmente vazio? Tentando reproduzir (com uma imagem de 12 TB, configurações padrão do mkfs bsize=4096 blocks=2929687500) , o df -hresultado é Size 11T, Used 12Gnão 78Gcomo no seu exemplo. xfsdumpproduz um arquivo de 21 KB ... ;-)
frostschutz 12/09
2
Ah, eu notei que você tinha, reflink=1mas o padrão para mim era reflink=0. Com reflink=1, também diz 78Gusado para mim, para que eu possa reproduzi-lo agora.
frostschutz 12/09
Portanto, parece que isso ocorre por design, mas se você tiver certeza de que os refletores não farão nada para o seu caso de uso, considere desativá-lo.
frostschutz 12/09
Eu não sei. A única coisa aqui serão os arquivos qcow2 para máquinas virtuais.
yakatz 12/09
Parece que algumas ferramentas libvirt suportam reflink, mas provavelmente não vale a pena: stackoverflow.com/a/41968000/597234 É provável que eu possa ajustar uma VM adicional no espaço economizado.
yakatz 12/09

Respostas:

2

Para o XFS, o sistema de arquivos vazio "Size Used", como mostrado por, df -hparece depender muito dos recursos de metadados que você ativa no mkfs.xfsmomento.

Testando com um arquivo de 12 TB vazio:

# truncate -s 12TB xfstest.img

Configurações padrão (no meu sistema ArchLinux atual):

# mkfs.xfs xfstest.img 
meta-data=xfstest.img            isize=512    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=2929687500, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount -o loop xfstest.img loop/
# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   12G   11T   1% /dev/shm/loop
# umount loop/

Usando reflink=1:

# mkfs.xfs -m reflink=1 -f xfstest.img
meta-data=xfstest.img            isize=512    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=2929687500, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount -o loop xfstest.img loop/
# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   78G   11T   1% /dev/shm/loop

Usando crc=0, reflink=0: (por alguma razão, que também se transforma finobt=0, sparse=0)

# mkfs.xfs -m reflink=0 -m crc=0 -f xfstest.img 
meta-data=xfstest.img            isize=256    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=2929687500, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount -o loop xfstest.img loop/
# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   33M   11T   1% /dev/shm/loop

Em resumo:

# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   78G   11T   1% /dev/shm/loop (reflink=1, crc=1)
/dev/loop0       11T   12G   11T   1% /dev/shm/loop (reflink=0, crc=1)
/dev/loop0       11T   33M   11T   1% /dev/shm/loop (reflink=0, crc=0)

Portanto, o espaço "usado" em um novo sistema de arquivos de 12 TB é 78G, 12G ou tão baixo quanto 33M, dependendo de quais recursos de metadados você ativa no momento do mkfs.

frostschutz
fonte
RedHat 8 tem reflinks=1por padrão
yakatz 31/10
24

Todos os sistemas de arquivos têm uma sobrecarga para suas próprias estruturas de dados internas. Essas informações internas são usadas para o sistema de arquivos criar arquivos e diretórios no futuro e acompanhar onde tudo está alocado. Esses dados são conhecidos coletivamente como "metadados". São dados "sobre" os dados no sistema de arquivos. Os metadados são considerados uma sobrecarga, pois ocupam espaço, mas não são dados do usuário. Essa sobrecarga é um efeito colateral inevitável do uso de qualquer sistema de arquivos.

De acordo com este post do blog , o XFS possui uma sobrecarga de cerca de 0,5% do espaço total em disco. (Observe que este post é de 2009, mas não há motivo para que isso tenha mudado drasticamente). Ele obteve esse resultado testando a sobrecarga do sistema de arquivos de mais de uma dúzia de sistemas de arquivos diferentes usando guestfish.

0,5% do seu espaço de 12 TB é de 60 GB, por isso parece muito próximo do uso esperado. Eu suspeito que o número dele deveria ter sido ligeiramente superior a 0,5%, mas foi arredondado.

Moshe Katz
fonte
9
Vale ressaltar que alguns sistemas de arquivos relatam o tamanho total alocado e cobram a sobrecarga da contabilidade pelo espaço usado, enquanto outros subtraem a contabilidade do tamanho total e relatam apenas o espaço no arquivo como "usado".
chrylis -on strike -
3
Sobrecarga do sistema de arquivos ... fazendo as pessoas perguntarem por que seus discos rígidos não informam o que está na etiqueta desde 1983.
J ...
3
@J ... Na verdade, o disco rígido costuma ser comercializado no tamanho de 1 GB = 1000 MB em vez de 1024 MB. Portanto, um HD comercializado com 512 GB é na verdade 12 GB menor que o tamanho listado. Fica ainda pior com a TB, pois eles usam 1 TB = 1000 GB = 1000 * 1000 MB. Um HD de 1TB é realmente um 976GB em vez de 1024GB. Um grito de 48GB perdido por TB.
Justin Lessard
4
A diferença na medição de gigabytes (base 10) vs gibibytes (base 2) não aparece como espaço usado df.
yakatz 12/09
11
@JustinLessard Você esqueceu a sobrecarga nos níveis MiB e KiB. Um disco rígido de 512 GB é, na verdade, mais de 32 GiB menor que um drive de 512 GiB real. E nisso, uma unidade de 1 TB é realmente mais parecida com 0,909 TiB ao contabilizar a sobrecarga de TiB, GiB, MiB e KiB. (1 * 1000 ^ 4/1024 ^ 4) = 0,90949
penguin359