Le système de fichiers XFS nouvellement créé montre que 78 Go sont utilisés

18

Nous avons une matrice RAID 6 de 12 To qui est censée être configurée comme une seule partition avec un système de fichiers XFS . Lors de la création du nouveau système de fichiers, il indique qu'il dispose de 78 Go, mais il n'y a aucun fichier sur le lecteur.

[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

Est-ce que j'ai fait quelque chose de mal? Est-ce par conception?

Il semble que le journal du système de fichiers ne prenne que 2 Go environ, et je ne peux pas comprendre ce qui pourrait être utilisé d'autre.

[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

Informations sur la partition:

[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

Il s'agit d'un Dell FX2 avec quatre nœuds de calcul FC430 et deux nœuds de stockage FD332, exécutant Red Hat Enterprise Linux 8 ( Ootpa ).

storage  partition  xfs  rhel8 
— yakatz
source
Est-ce vraiment vide? Essayer de reproduire (avec une image de 12 To, les paramètres mkfs par défaut bsize=4096 blocks=2929687500), le df -hrésultat n'est Size 11T, Used 12Gpas conforme 78Gà votre exemple. xfsdumpproduit un fichier de 21 Ko ... ;-)
— frostschutz
2
Ah, je remarque que vous en aviez, reflink=1mais le défaut pour moi était reflink=0. Avec reflink=1, il dit aussi 78Gutilisé pour moi, donc je peux le reproduire maintenant.
— frostschutz
Il semble donc que ce soit par conception, mais si vous êtes sûr que les reflinks ne feront rien pour votre cas d'utilisation, vous pouvez envisager de le désactiver.
— frostschutz
Je ne sais pas. La seule chose ici sera les fichiers qcow2 pour les machines virtuelles.
— yakatz
Il semble que certains outils libvirt prennent en charge le reflink, mais cela ne vaut probablement pas la peine: stackoverflow.com/a/41968000/597234 Je peux probablement installer une machine virtuelle supplémentaire dans l'espace enregistré.
— yakatz

Réponses:

2

Pour XFS, le système de fichiers vide "Taille utilisée" comme indiqué par df -hsemble dépendre beaucoup des fonctionnalités de métadonnées que vous activez à la mkfs.xfsfois.

Test avec un fichier vide de 12 To:

# truncate -s 12TB xfstest.img

Paramètres par défaut (sur mon système ArchLinux actuel):

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

En utilisant 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

En utilisant crc=0, reflink=0: (pour une raison quelconque, qui tourne aussi 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

En bref:

# 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)

Ainsi, l'espace "utilisé" sur un nouveau système de fichiers de 12 To est 78G, 12G ou aussi bas que 33M selon les fonctionnalités de métadonnées que vous activez au moment mkfs.

— frostschutz
source
RedHat 8 a reflinks=1par défaut
— yakatz
24

Tous les systèmes de fichiers ont une surcharge pour leurs propres structures de données internes. Ces informations internes sont utilisées par le système de fichiers pour créer des fichiers et des répertoires à l'avenir et pour savoir où tout est alloué. Ces données sont collectivement appelées «métadonnées». Ce sont des données "sur" les données du système de fichiers. Les métadonnées sont considérées comme des frais généraux, car elles occupent de l'espace mais ne sont pas des données utilisateur. Cette surcharge est un effet secondaire inévitable de l'utilisation de tout système de fichiers.

Selon ce billet de blog , XFS a une surcharge d'environ 0,5% de l'espace disque total. (Notez que ce post date de 2009, mais il n'y a aucune raison pour que cela ait radicalement changé). Il a obtenu ce résultat en testant la surcharge du système de fichiers de plus d'une douzaine de systèmes de fichiers différents en utilisant guestfish.

0,5% de votre espace de 12 To est de 60 Go, il semble donc que cela soit assez proche de l'utilisation attendue. Je soupçonne que son nombre aurait dû être légèrement supérieur à 0,5%, mais qu'il a été arrondi.

— Moshe Katz
source
9
Il convient de noter que certains systèmes de fichiers signalent la taille totale allouée, puis facturent les frais généraux de comptabilité à l'espace utilisé, tandis que d'autres soustraient la comptabilité de la taille réelle et signalent uniquement l'espace fichier comme «utilisé».
— chrylis -on strike-
3
Frais généraux du système de fichiers ... obligeant les gens à demander pourquoi leurs disques durs ne signalent pas ce qui est sur l'autocollant depuis 1983.
— J ...
3
@J ... En fait, le disque dur commercialise souvent sa taille en utilisant 1 Go = 1000 Mo au lieu de 1024 Mo. Un HD commercialisé à 512 Go est donc 12 Go plus petit que la taille indiquée. C'est encore pire avec la tuberculose car ils utilisent 1 To = 1000 Go = 1000 * 1000 Mo. Un 1 To HD est vraiment un 976 Go au lieu de 1024 Go. Une coqueluche de 48 Go perdue par la tuberculose.
— Justin Lessard
4
La différence entre la mesure des gigaoctets (base 10) et des gibibytes (base 2) ne s'affiche pas comme espace utilisé dans df.
— yakatz
1
@JustinLessard Vous avez oublié les frais généraux aux niveaux MiB et KiB. Un disque dur de 512 Go est en fait plus de 32 Gio plus petit qu'un vrai lecteur de 512 Gio. Et là-dessus, un lecteur de 1 To ressemble beaucoup plus à 0,909 TiB lors de la prise en compte des frais généraux TiB, GiB, MiB et KiB. (1 * 1000 ^ 4/1024 ^ 4) = 0,90949
— pingouin359
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.