Вопросы Теги

Понимание переменных состояния сжатия 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% (это ожидается, объем почти полностью файлов данных Carbon, которые в основном пусты, поэтому они должны быть чрезвычайно сжимаемыми).

Однако, если я задаю 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 представляет его статус.

Googling вокруг, я не могу найти документация на члене 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
задан 30 December 2017 в 13:37

3 ответа

Похоже, 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                  -

Ничего не изменилось, хотя нулевой файл следует считать довольно хорошим сжимаемым. При использовании sparsefiles пространство никогда не выделяется прямо сейчас, а только по требованию. Это поведение в любой файловой системе, так как это независимая от файловой системы. Все, что делается, это установить параметр «Размер», но не выделяет никаких блоков, как вы можете видеть из 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: -

Итак, нулевой файл и нулевой файл выглядят почти одинаково и имеют только один выделенный блок. Если мы сделаем то же самое на [ f15], мы можем видеть разницу, поскольку выделены блоки для Size . 

[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: -

Теперь давайте рассмотрим пример с файлом, содержащий только символ [ f16] с размером 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.

1
ответ дан 22 May 2018 в 15:51
  • 1
    Круто! Кроме того, почему-то я не знал о команде stat. Единственный комментарий, который у меня есть, это то, что цитируемый комментарий о ext4 sparsefiles не кажется правильным, поскольку я перешел из ext4 в ZFS, потому что ext4 выделял весь разреженный файл при создании. Возможно, это связано с тем, что программное обеспечение, создающее файл, не создает разреженный файл таким образом, как ожидает ext4, и только ZFS достаточно умен, чтобы понять, что это фактически разреженный файл. – Fake Name 31 December 2017 в 04:03
  • 2
    Что касается sparsefile, если пространство выделяется при создании файла, то это не разреженный файл. Редкий файл - это не определенный тип файла, а метод выделения или сохранения пространства. – Thomas 31 December 2017 в 12:46

Похоже, 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 -

Ничего не изменилось, хотя нулевой файл следует считать довольно хорошим сжимаемым. При использовании sparsefiles пространство никогда не выделяется прямо сейчас, а только по требованию. Это поведение в любой файловой системе, так как это независимая от файловой системы. Все, что делается, это установить параметр «Размер», но не выделяет никаких блоков, как вы можете видеть из 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: -

Итак, нулевой файл и нулевой файл выглядят почти одинаково и имеют только один выделенный блок. Если мы сделаем то же самое на ext4, мы можем видеть разницу, поскольку выделены блоки для Size .

[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.

1
ответ дан 18 July 2018 в 00:12

Похоже, 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 -

Ничего не изменилось, хотя нулевой файл следует считать довольно хорошим сжимаемым. При использовании sparsefiles пространство никогда не выделяется прямо сейчас, а только по требованию. Это поведение в любой файловой системе, так как это независимая от файловой системы. Все, что делается, это установить параметр «Размер», но не выделяет никаких блоков, как вы можете видеть из 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: -

Итак, нулевой файл и нулевой файл выглядят почти одинаково и имеют только один выделенный блок. Если мы сделаем то же самое на ext4, мы можем видеть разницу, поскольку выделены блоки для Size .

[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.

1
ответ дан 24 July 2018 в 17:10

Другие вопросы по тегам:

Похожие вопросы: