J'ai un environnement virtualisé très haute densité avec des conteneurs, j'essaie donc de rendre chaque conteneur vraiment petit. "Vraiment petit" signifie 87 Mo sur la base Ubuntu 14.04 (Trusty Tahr) sans rompre la compatibilité du gestionnaire de paquets.
J'utilise donc LVM comme stockage de sauvegarde pour mes conteneurs et récemment, j'ai trouvé des nombres très étranges. Les voici.
Créons un volume logique de 100 Mio (ouais, puissance de 2).
sudo lvcreate -L100M -n test1 /dev/purgatory
Je voudrais vérifier la taille, alors je publie sudo lvs --units k
test1 purgatory -wi-a---- 102400.00k
Doux, c'est vraiment 100 MiB.
Faisons maintenant un système de fichiers ext4 . Et bien sûr, nous nous souvenons du -m 0paramètre qui évite les pertes d’espace.
sudo mkfs.ext4 -m 0 /dev/purgatory/test1
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
Doux et propre. Attention à la taille des blocs - notre volume logique est petit, donc mkfs.ext4 a décidé de créer un bloc de 1 Ko, et non les 4 Ko habituels.
Maintenant nous allons le monter.
sudo mount /dev/purgatory/test1 /mnt/test1
Et appelons dfsans paramètres (nous aimerions voir 1 blocs KiB)
/dev/mapper/purgatory-test1 95054 1550 91456 2% /mnt/test1
Attends, oh shi ~
Nous avons 95054 blocs au total. Mais l'appareil lui-même a 102400 blocs de 1 KiB. Nous n'avons que 92,8% de notre stockage. Où sont mes blocs, mec?
Regardons cela sur un vrai périphérique en mode bloc. A ont un disque virtuel de 16 Go, 16777216 blocs de 1K, mais seuls 15396784 blocs sont en sortie df. 91,7%, c'est quoi?
Suit maintenant l'enquête (spoiler: aucun résultat)
Le système de fichiers pourrait ne pas commencer au début de l'appareil. C'est étrange, mais possible. Heureusement, ext4 a des octets magiques, vérifions leur présence.
sudo hexdump -C / dev / purgatoire / test1 | grep "53 ef"
Cela montre superbloc:
00000430 a9 10 e7 54 01 00 ff ff 53 ef 01 00 01 00 00 00 |...T....S.......|
Hex 430 = Dec 1072, donc quelque part après le premier kilo-octet. Apparemment, ext4 saute les 1024 premiers octets pour les bizarreries comme VBR, etc.
- C'est un journal!
Non ce n'est pas. Le journal prend de l'espace de Disponible si sortie df.
- Oh, nous avons dump2fs et pourrions vérifier les tailles ici!
... beaucoup de greps ...
sudo dumpe2fs /dev/purgatory/test1 | grep "Free blocks"
Aie.
Free blocks: 93504
Free blocks: 3510-8192
Free blocks: 8451-16384
Free blocks: 16385-24576
Free blocks: 24835-32768
Free blocks: 32769-40960
Free blocks: 41219-49152
Free blocks: 53249-57344
Free blocks: 57603-65536
Free blocks: 65537-73728
Free blocks: 73987-81920
Free blocks: 81921-90112
Free blocks: 90113-98304
Free blocks: 98305-102399
Et nous avons un autre numéro. 93504 blocs gratuits.
La question est: que se passe-t-il?
- Périphérique de blocage: 102400k (dit LVS)
- Taille du système de fichiers: 95054k (df dit)
- Blocs gratuits: 93504k (dumpe2fs dit)
- Taille disponible: 91456k (df dit)
ext2pour les petites partitions.ext2semble raisonnable ici, bien sûrRéponses:
Essaye ça:
mkfs.ext4 -N 104 -m0 -O ^has_journal,^resize_inode /dev/purgatory/test1Je pense que cela vous laisse comprendre "ce qui se passe".
-N 104(définissez le nombre d'iNodes que votre système de fichiers devrait avoir)-m 0(pas de blocs réservés)-O ^has_journal,^resize_inode(désactivez les fonctionshas_journaletresize_inoderesize_inode"coûte" de l' espace libre (la plupart des 1550 blocs de 1K / 2% que vous voyez dans votredf- 12K sont utilisés pour le dossier "perdu + trouvé")has_journal"coûte" l' espace utilisable (4096 1K-Blocks dans votre cas)Nous
102348sortons de102400, 52 autres blocs inutilisables (si nous avons supprimé le dossier "lost + found"). Nous plongeons donc dansdumpe2fs:et comptez les blocs utilisés (pour le superbloc de sauvegarde, les descripteurs de groupe, le bitmap de bloc, le bitmap d’inode et le tableau Inode) ou bien nous
grepcomptons:qui nous donne le nombre de lignes qui ont un seul bloc (dans notre exemple) et
ce qui nous donne le nombre de lignes qui ont deux blocs (dans notre exemple).
Nous avons donc (dans notre exemple) des
13lignes avec un bloc chacune et des19lignes avec deux blocs chacune.ce qui nous donne des
51blocs qui sont utilisés par ext4 lui-même. Enfin, il ne reste qu'un bloc. Le bloc 0, qui sont les1024octets ignorés au début pour des choses comme le secteur de démarrage.la source
dfsur fs avec journal: 95054k -dfsur fs sans jorunal 99150k - et ne mélangez pas les espaces "utilisable" et "libre".mkfs.xfs -l size=512 -d agcount=1créera un système de fichiers avec la taille minimale absolue du journal (journal), mais les performances en écriture pourraient en souffrir. Je ne pense pas que le code XFS supporte le fonctionnement sans journal. Peut-être en lecture seule, pour prendre en charge les cas où un périphérique de journalisation externe est endommagé. (Aussi,agcount=1est probablement une autre idée terrible pour la performance en écriture, en particulier parallèle. Et les en-têtes de groupe d'allocation sont probablement petits également.)mkfs.xfs -d agcount=1sur une partition de 100 Mo faite un FS de 95980kiB, avec 5196k utilisé, 90784k disponible. Le nombre d'agents par défaut est 4 et la taille de journal par défaut est de 1605 blocs (également le minimum). Donc, XFS utilise un journal aussi petit qu'il est prêt à vous laisser spécifier, pour les petits FS.La réponse courte:
Tout l'espace sur le périphérique en bloc ne devient pas un espace disponible pour vos données: une partie de l'espace brut est nécessaire pour les internes du système de fichiers, la comptabilité en arrière-plan.
Cette comptabilité comprend le superbloc, les descripteurs de groupe de blocs, les bitmaps de blocs et d’inodes et la table inode. De plus, des copies du superbloc à des fins de sauvegarde / récupération sont créées à plusieurs endroits. Une longue lecture sur les composants internes du système de fichiers EXT4 se trouve sur ext4.wiki.kernel.org .
Depuis EXT4 est un système de fichiers journalisé qui prend également de la place.
De plus, de l'espace est réservé pour de futures extensions du système de fichiers.
La réponse longue:
J'ai recréé votre scénario sur l'un de mes systèmes de test:
Ensuite, avant même de monter le système de fichiers, a
dumpe2fsmontre:et après montage:
Alors qu'est-ce que
dfnous montre? Sur les 102400 blocs de capacité de stockage brute, 99150 blocs sont visibles pour le système de fichiers, ce qui signifie que 3250 blocs d'espace mémoire brut de 1 kilo-octet sont devenus inutilisables pour le stockage de données.Où sont allés ces blocs? Faire défiler vers le bas dans la
dumpe2fssortie montre exactement où:1 block(bloc 0) Les 1024 premiers octets sont ignorés pour permettre l'installation de secteurs d'amorçage x86 et d'autres bizarreries.1 blockest occupé par le superbloc primaire.1 blockcontient les descripteurs de groupe.256 blockssont réservés pour la table de descripteur de groupe afin de permettre un redimensionnement ultérieur du système de fichiers.16 blockssont attribués pour le bitmap de bloc.16 blockssont attribués pour le bitmap inode.246 blockssont affectés à la table inode.Cela représente déjà 537 des 3 250 blocs manquants. Un système de fichiers ext4 est divisé en une série de groupes de blocs et le défilement vers le bas montre également une allocation similaire de la capacité de stockage brute aux internes du système de fichiers des autres groupes de blocs:
Revenons maintenant à la
dfsortie:La raison pour laquelle 7% de la capacité déjà utilisée sur ce nouveau système de fichiers est marquée comme étant en cours d'utilisation est la suivante:
99150 (taille du système de fichiers) MOINS 5120 (nombre de blocs réservés) MOINS 5646 (blocs utilisés, dont 4096 extraits du Journal (faisant également partie de la sortie de dumpe2fs`))
= 88384
Le nombre de blocs libres dans dumpe2fs est la taille disponible du système de fichiers moins l'utilisation réelle (et ne prend pas en compte les blocs réservés), donc 99150 - 5646 = 93504.
la source
Pas une réponse à la question, mais je suis devenu curieux alors j'imagine que d'autres le feront. Comme j'avais déjà démarré un liveCD et que j'avais un disque dur avec lequel je pouvais jouer sans me soucier des fautes de frappe, je suis allé de l'avant et j'ai testé.
J'ai créé des partitions avec tous les systèmes de stockage pour lesquels Ubuntu 14.10 fournit un fichier mkfs, sur des partitions de 100 Mo. (sauf minix, qui ne supporte que 64MiB, et bfs, ce qui est quelque chose de SCO dont je n'ai jamais entendu parler.)
D' abord , je regardais l'
df -kespace disponible (avec les paramètres de mkfs par défaut), alorsddj'ed/dev/zerodans un fichier sur chaque FS pour vous assurer qu'ils pourraient remplir toute la hauteur. (c.-à-d. vérifier que la réclamationavailable spaceétait vraiment disponible.)for i in /media/ubuntu/small-*;do sudo dd if=/dev/zero of="$i/fill" bs=16k;donePourquoi btrfs a-t-il autant d'espace inutilisable? Peut-être pour les métadonnées? bien nope:
Les deux systèmes de fichiers basés sur des arbres ne peuvent pas compresser un fichier vide n'importe où, mais tous les autres peuvent.
Ou regardez simplement la taille d'un fichier que vous pouvez créer:
(J'ai appelé ma partition ext4 "small-ext" parce que je n'avais pas l'intention de devenir dingue et de créer tous les systèmes de fichiers. So ext = ext4 ici. PAS l'original pré-ext2 ext.)
Et
df -ksortie après les avoir à nouveau enlevés:(jfs est revenu à 1% utilisé après que j'ai supprimé "touché" également. Soit il y avait un délai, soit il a fallu une autre écriture pour obtenir la taille disponible à mettre à jour.)
Quoi qu'il en soit, je pense que c'est à peu près tout pour ma curiosité.
la source