Понимание переменных состояния сжатия в Ubuntu ZFS
У меня есть Ubuntu VM, у которой есть объем, содержащий несколько очень, очень сжимаемых наборов данных.
По этой причине я преобразовал рассматриваемый том в том ZFS, потому что тогда я могу использовать сжатие ZFS.
Все это работает очень хорошо, но я смущен некоторыми выводами статуса ZFS.
durr@graphical:/tank$ du . -h --max-depth=1; echo -----; du . -h --apparent-size --max-depth=1
1.9G ./carbon
1.9G .
-----
193G ./carbon
193G .
Примечание: /tank/ - это точка монтирования тома ZFS.
Итак, приведите выше, в настоящее время я получаю степень сжатия ~ 1% (это Ожидается, что объем почти полностью файлов данных углерода , которые в основном пусты, поэтому они должны быть чрезвычайно сжимаемыми).
Однако, если я спрашиваю ZFS о громкости:
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 сообщает о степени сжатия 4.39x или 4.40x, в зависимости от того, куда вы смотрите. Тем не менее, с коэффициентом сжатия ~ 1% от предыдущего, я ожидаю увидеть либо 0,01x, либо 99,0x, в зависимости от того, как ZFS представляет свой статус.
Погуглив, я не могу найти документацию по участнику compressratio. Это определенно меняется, когда вы перемещаете данные, потому что я видел, как они меняются, но что это на самом деле говорит мне?
Если подумать, у меня также включена дедупликация ZFS для этого тома, поэтому Я думал, что это может быть дедупликация пустых блоков. Однако, это не кажется правильным:
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
Я понятия не имею, где находятся дополнительные данные, с точки зрения ZFS. Я думаю, что файлы редки. Разве ZFS не выделяет дисковое пространство для разреженных файлов немедленно?
1 ответ
Похоже, что ZFS превращает пустой файл в разреженный файл, когда сжатие включено. Взято из комментария DeHackEd отсюда .
Наиболее вероятный ответ на ваш вопрос: разреженные отверстия не считаются «сжатыми». Это дыры. Вы получаете то же самое на ext4, и он вообще не поддерживает сжатие. ZFS превратит все пустые страницы в разреженные дыры, когда сжатие включено.
Я также создал несколько файлов в наборе данных ZFS, используя sparsefile, файл, созданный из /dev/zero, и файл, созданный только с символом a, чтобы получить хорошее сжатие.
Команды, используемые для создания файлов.
-
truncate -s $((1024*1024*1024)) /tank1/sparsefile -
dd if=/dev/zero of=/tank1/zerofile bs=1073741824 count=1 - использовали некоторые для петель, чтобы повторить
aвafile
Сначала проверьте сжатие на пустом наборе файлов tank1.
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 1.00x -
tank1 compression lz4 local
tank1 refcompressratio 1.01x -
Затем создайте разреженный файл и файл из /dev/zero размером 1 ГБ и снова проверьте сжатие.
[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 -
Ничего не изменилось, хотя zerofile следует рассматривать как довольно хорошо сжимаемый. При использовании разреженных файлов пространство никогда не выделяется прямо сейчас, а только по требованию. Это поведение в любой файловой системе, поскольку оно не зависит от файловой системы.
Все, что делается, - это установить параметр Size , но не выделяет никаких блоков, как вы можете видеть из 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: -
Таким образом, sparsefile и zerofile выглядят практически одинаково и имеют только один выделенный блок.
Если мы сделаем то же самое в файловой системе ext4, мы сможем увидеть разницу, когда выделены блоки для нулевого файла .
[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: -
Теперь давайте рассмотрим пример с файлом, содержащим только символ a размером 1 ГБ в 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 -
Довольно хорошая степень сжатия, и она отличается от файла, содержащего zeros.