Comprendre les variables d'état de la compression ubuntu ZFS
J'ai un Ubuntu VM qui a un volume contenant des jeux de données très compressibles très .
Pour cette raison, j'ai converti le volume en question en un volume ZFS, car je peux ensuite utiliser la compression ZFS.
Tout cela fonctionne très bien, mais certaines des sorties de statut ZFS me déroutent.
durr@graphical:/tank$ du . -h --max-depth=1; echo -----; du . -h --apparent-size --max-depth=1
1.9G ./carbon
1.9G .
-----
193G ./carbon
193G .
Remarque: /tank/ est le point de montage du volume ZFS.
Donc, donnez ce qui précède, je reçois actuellement un taux de compression de ~ 1% (ce qui est prévu, le volume est presque entièrement Carbon fichiers de données, qui sont pour la plupart vides, ils devraient donc être extrêmement compressibles).
Cependant, si je demande à ZFS le volume:
durr@graphical:/tank$ Sudo zfs get all tank
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Mon Dec 25 7:27 2017 -
tank used 1.87G -
tank available 239G -
tank referenced 1.85G -
tank compressratio 4.39x -
tank mounted yes -
tank quota none default
tank reservation none default
tank recordsize 128K default
tank mountpoint /tank default
tank sharenfs off default
tank checksum on default
tank compression on local
tank atime on default
tank devices on default
tank exec on default
tank setuid on default
tank readonly off default
tank zoned off default
tank snapdir hidden default
tank aclinherit restricted default
tank canmount on default
tank xattr on default
tank copies 1 default
tank version 5 -
tank utf8only off -
tank normalization none -
tank casesensitivity sensitive -
tank vscan off default
tank nbmand off default
tank sharesmb off default
tank refquota none default
tank refreservation none default
tank primarycache all default
tank secondarycache all default
tank usedbysnapshots 0 -
tank usedbydataset 1.85G -
tank usedbychildren 18.7M -
tank usedbyrefreservation 0 -
tank logbias latency default
tank dedup on local
tank mlslabel none default
tank sync standard default
tank refcompressratio 4.40x -
tank written 1.85G -
tank logicalused 8.13G -
tank logicalreferenced 8.13G -
tank filesystem_limit none default
tank snapshot_limit none default
tank filesystem_count none default
tank snapshot_count none default
tank snapdev hidden default
tank acltype off default
tank context none default
tank fscontext none default
tank defcontext none default
tank rootcontext none default
tank relatime on temporary
tank redundant_metadata all default
tank overlay off default
ZFS signale un taux de compression de 4.39x ou 4.40x, selon l'endroit où vous regardez. Cependant, avec le taux de compression de ~ 1% précédemment, je m'attendrais à voir 0.01x ou 99.0x, selon la façon dont ZFS représente son statut.
Je ne trouve pas la documentation sur le membre compressratio dans Google. Cela change définitivement au fur et à mesure que vous déplacez les données, parce que je les ai vu varier, mais que me dit-il réellement?
En y réfléchissant, la déduplication ZFS est également activée pour ce volume. J'ai donc pensé que cela pourrait être une déduplication des blocs vides. Cependant, cela ne semble pas correct:
durr@graphical:/tank$ Sudo zpool get all tank
NAME PROPERTY VALUE SOURCE
tank size 248G -
tank capacity 0% -
tank altroot - default
tank health ONLINE -
tank guid 11995166271724776732 default
tank version - default
tank bootfs - default
tank delegation on default
tank autoreplace off default
tank cachefile - default
tank failmode wait default
tank listsnapshots off default
tank autoexpand off default
tank dedupditto 0 default
tank dedupratio 1.12x -
tank free 246G -
tank allocated 1.69G -
tank readonly off -
tank ashift 0 default
tank comment - default
tank expandsize - -
tank freeing 0 default
tank fragmentation 1% -
tank leaked 0 default
tank feature@async_destroy enabled local
tank feature@empty_bpobj enabled local
tank feature@lz4_compress active local
tank feature@spacemap_histogram active local
tank feature@enabled_txg active local
tank feature@hole_birth active local
tank feature@extensible_dataset enabled local
tank feature@embedded_data active local
tank feature@bookmarks enabled local
tank feature@filesystem_limits enabled local
tank feature@large_blocks enabled local
Je ne sais pas du tout où se trouvent les données supplémentaires, du point de vue de ZFS. Je pense que les fichiers sont rares. ZFS ne dédie-t-il pas immédiatement l'espace disque aux fichiers fragmentés?
Il semble que ZFS transforme un fichier null en fichier sparse lorsque la compression est activée. Tiré du commentaire de DeHackEd d'ici .
La réponse la plus probable à votre question est la suivante: les trous épars ne sont pas considérés comme "compressés". Ils sont des trous. Vous obtenez la même chose sur ext4 et il ne supporte pas du tout la compression. ZFS transformera toutes les pages vierges en trous minces lorsque la compression est activée.
J'ai également créé des fichiers sur un jeu de données ZFS en utilisant un sparsefile, un fichier créé à partir de /dev/zero et un fichier créé uniquement avec le caractère a pour obtenir une bonne compression.
Commandes utilisées pour créer les fichiers.
truncate -s $((1024*1024*1024)) /tank1/sparsefiledd if=/dev/zero of=/tank1/zerofile bs=1073741824 count=1- utilisé quelques boucles pour faire écho
adans leafile
Commencez par vérifier le compressratio sur le groupe de fichiers vide tank1.
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 1.00x -
tank1 compression lz4 local
tank1 refcompressratio 1.01x -
Créez ensuite un fichier sparsefile et un fichier de /dev/zero d'une taille de 1 Go, puis vérifiez à nouveau le fichier compressé.
[root@localhost tank1]# truncate -s $((1024*1024*1024)) sparsefile
[root@localhost tank1]# dd if=/dev/zero of=/tank1/zerofile bs=1073741824 count=1
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 1.00x -
tank1 compression lz4 local
tank1 refcompressratio 1.01x -
Rien n'a changé, bien que le zerofile soit considéré comme assez compressible. Avec sparsefiles, l’espace n’est jamais alloué pour le moment, mais uniquement à la demande. C'est le comportement de tout système de fichiers car il est indépendant du système de fichiers.
Tout ce qui est fait est de définir le paramètre Taille , mais n'alloue aucun bloc comme vous pouvez le voir dans stat .
[root@localhost tank1]# stat sparsefile
File: ‘sparsefile’
Size: 1073741824 Blocks: 1 IO Block: 131072 regular file
Device: 2ah/42d Inode: 2 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-12-30 15:31:37.512845721 +0100
Modify: 2017-12-30 15:31:37.513845720 +0100
Change: 2017-12-30 15:31:37.513845720 +0100
Birth: -
[root@localhost tank1]# stat zerofile
File: ‘zerofile’
Size: 1073741824 Blocks: 1 IO Block: 131072 regular file
Device: 2ah/42d Inode: 3 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-12-30 15:31:41.742838662 +0100
Modify: 2017-12-30 15:31:42.616837203 +0100
Change: 2017-12-30 15:31:42.616837203 +0100
Birth: -
Ainsi, le fichier sparse et le zerofile sont à peu près identiques et ne possèdent que 1 bloc alloué.
Si nous faisons la même chose sur un système de fichiers ext4, nous pouvons voir la différence lorsque les blocs pour le zerofile sont alloués .
[root@localhost test]$ stat sparsefile
File: sparsefile
Size: 1073741824 Blocks: 0 IO Block: 4096 regular file
Device: fd02h/64770d Inode: 2883724 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ root) Gid: ( 1000/ root)
Access: 2017-12-30 15:53:46.477442716 +0100
Modify: 2017-12-30 15:53:46.477442716 +0100
Change: 2017-12-30 15:53:46.477442716 +0100
Birth: -
[root@localhost test]$ stat zerofile
File: zerofile
Size: 1073741824 Blocks: 2097160 IO Block: 4096 regular file
Device: fd02h/64770d Inode: 2884453 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ root) Gid: ( 1000/ root)
Access: 2017-12-30 15:54:11.014403727 +0100
Modify: 2017-12-30 15:54:11.311403254 +0100
Change: 2017-12-30 15:54:11.311403254 +0100
Birth: -
Examinons maintenant un exemple avec un fichier contenant uniquement le caractère a d’une taille de 1 Go sous ZFS.
[root@localhost tank1]# du -h afile
33M afile
[root@localhost tank1]# du -h afile --apparent-size
1.0G afile
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 31.16x -
tank1 compression lz4 local
tank1 refcompressratio 31.89x -
Le taux de compression est plutôt bon et il diffère d'un fichier contenant zeros.