странный отчет об использовании дискового пространства ZFS для ZVOL

8

У нас есть 100G ZVOL на хосте FreeBSD 10.0-CURRENT, который утверждает, что использует 176G дискового пространства:

root@storage01:~ # zfs get all zroot/DATA/vtest
NAME              PROPERTY              VALUE                  SOURCE
zroot/DATA/vtest  type                  volume                 -
zroot/DATA/vtest  creation              Fri May 24 20:44 2013  -
zroot/DATA/vtest  used                  176G                   -
zroot/DATA/vtest  available             10.4T                  -
zroot/DATA/vtest  referenced            176G                   -
zroot/DATA/vtest  compressratio         1.00x                  -
zroot/DATA/vtest  reservation           none                   default
zroot/DATA/vtest  volsize               100G                   local
zroot/DATA/vtest  volblocksize          8K                     -
zroot/DATA/vtest  checksum              fletcher4              inherited from zroot
zroot/DATA/vtest  compression           off                    default
zroot/DATA/vtest  readonly              off                    default
zroot/DATA/vtest  copies                1                      default
zroot/DATA/vtest  refreservation        none                   local
zroot/DATA/vtest  primarycache          all                    default
zroot/DATA/vtest  secondarycache        all                    default
zroot/DATA/vtest  usedbysnapshots       0                      -
zroot/DATA/vtest  usedbydataset         176G                   -
zroot/DATA/vtest  usedbychildren        0                      -
zroot/DATA/vtest  usedbyrefreservation  0                      -
zroot/DATA/vtest  logbias               latency                default
zroot/DATA/vtest  dedup                 off                    default
zroot/DATA/vtest  mlslabel                                     -
zroot/DATA/vtest  sync                  standard               default
zroot/DATA/vtest  refcompressratio      1.00x                  -
zroot/DATA/vtest  written               176G                   -
zroot/DATA/vtest  logicalused           87.2G                  -
zroot/DATA/vtest  logicalreferenced     87.2G                  -
root@storage01:~ #

Это похоже на ошибку, как он может потреблять больше, чем его, volsizeесли у него нет снимков, резервирования и детей? Или, может быть, мы что-то упустили?

UPD:

Результаты zpool status -v:

root@storage01:~ # zpool status -v
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 0h6m with 0 errors on Thu May 30 05:45:11 2013
config:

        NAME           STATE     READ WRITE CKSUM
        zroot          ONLINE       0     0     0
          raidz2-0     ONLINE       0     0     0
            gpt/disk0  ONLINE       0     0     0
            gpt/disk1  ONLINE       0     0     0
            gpt/disk2  ONLINE       0     0     0
            gpt/disk3  ONLINE       0     0     0
            gpt/disk4  ONLINE       0     0     0
            gpt/disk5  ONLINE       0     0     0
        cache
          ada0s2       ONLINE       0     0     0

errors: No known data errors
root@storage01:~ #

Результаты zpool list:

root@storage01:~ # zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zroot  16.2T   288G  16.0T     1%  1.05x  ONLINE  -
root@storage01:~ #

Результаты zfs list:

root@storage01:~ # zfs list
NAME                            USED  AVAIL  REFER  MOUNTPOINT
zroot                           237G  10.4T   288K  /
zroot/DATA                      227G  10.4T   352K  /DATA
zroot/DATA/NFS                  288K  10.4T   288K  /DATA/NFS
zroot/DATA/hv                  10.3G  10.4T   288K  /DATA/hv
zroot/DATA/hv/hv001            10.3G  10.4T   144K  -
zroot/DATA/test                 288K  10.4T   288K  /DATA/test
zroot/DATA/vimage              41.3G  10.4T   288K  /DATA/vimage
zroot/DATA/vimage/vimage_001   41.3G  10.5T  6.47G  -
zroot/DATA/vtest                176G  10.4T   176G  -
zroot/SYS                      9.78G  10.4T   288K  /SYS
zroot/SYS/ROOT                  854M  10.4T   854M  /
zroot/SYS/home                 3.67G  10.4T  3.67G  /home
zroot/SYS/tmp                   352K  10.4T   352K  /tmp
zroot/SYS/usr                  4.78G  10.4T   427M  /usr
zroot/SYS/usr/local             288K  10.4T   288K  /usr/local
zroot/SYS/usr/obj              3.50G  10.4T  3.50G  /usr/obj
zroot/SYS/usr/ports             895K  10.4T   320K  /usr/ports
zroot/SYS/usr/ports/distfiles   288K  10.4T   288K  /usr/ports/distfiles
zroot/SYS/usr/ports/packages    288K  10.4T   288K  /usr/ports/packages
zroot/SYS/usr/src               887M  10.4T   887M  /usr/src
zroot/SYS/var                   511M  10.4T  1.78M  /var
zroot/SYS/var/crash             505M  10.4T   505M  /var/crash
zroot/SYS/var/db               1.71M  10.4T  1.43M  /var/db
zroot/SYS/var/db/pkg            288K  10.4T   288K  /var/db/pkg
zroot/SYS/var/empty             288K  10.4T   288K  /var/empty
zroot/SYS/var/log               647K  10.4T   647K  /var/log
zroot/SYS/var/mail              296K  10.4T   296K  /var/mail
zroot/SYS/var/run               448K  10.4T   448K  /var/run
zroot/SYS/var/tmp               304K  10.4T   304K  /var/tmp
root@storage01:~ #

Upd 2:

Мы создали несколько ZVOL с различными параметрами и использовали их ddдля перемещения контента. Мы заметили еще одну странную вещь: использование диска было нормальным для ZVOL с 16k и 128k, volblocksizeи оно оставалось ненормальным для ZVOL с 8k volblocksizeдаже после этого dd(так что это не проблема фрагментации):

root@storage01:~ # zfs get all zroot/DATA/vtest-3
NAME                PROPERTY              VALUE                  SOURCE
zroot/DATA/vtest-3  type                  volume                 -
zroot/DATA/vtest-3  creation              Fri May 31  7:35 2013  -
zroot/DATA/vtest-3  used                  201G                   -
zroot/DATA/vtest-3  available             10.2T                  -
zroot/DATA/vtest-3  referenced            201G                   -
zroot/DATA/vtest-3  compressratio         1.00x                  -
zroot/DATA/vtest-3  reservation           none                   default
zroot/DATA/vtest-3  volsize               100G                   local
zroot/DATA/vtest-3  volblocksize          8K                     -
zroot/DATA/vtest-3  checksum              fletcher4              inherited from zroot
zroot/DATA/vtest-3  compression           off                    default
zroot/DATA/vtest-3  readonly              off                    default
zroot/DATA/vtest-3  copies                1                      default
zroot/DATA/vtest-3  refreservation        103G                   local
zroot/DATA/vtest-3  primarycache          all                    default
zroot/DATA/vtest-3  secondarycache        all                    default
zroot/DATA/vtest-3  usedbysnapshots       0                      -
zroot/DATA/vtest-3  usedbydataset         201G                   -
zroot/DATA/vtest-3  usedbychildren        0                      -
zroot/DATA/vtest-3  usedbyrefreservation  0                      -
zroot/DATA/vtest-3  logbias               latency                default
zroot/DATA/vtest-3  dedup                 off                    default
zroot/DATA/vtest-3  mlslabel                                     -
zroot/DATA/vtest-3  sync                  standard               default
zroot/DATA/vtest-3  refcompressratio      1.00x                  -
zroot/DATA/vtest-3  written               201G                   -
zroot/DATA/vtest-3  logicalused           100G                   -
zroot/DATA/vtest-3  logicalreferenced     100G                   -
root@storage01:~ #

а также

root@storage01:~ # zfs get all zroot/DATA/vtest-16
NAME                 PROPERTY              VALUE                  SOURCE
zroot/DATA/vtest-16  type                  volume                 -
zroot/DATA/vtest-16  creation              Fri May 31  8:03 2013  -
zroot/DATA/vtest-16  used                  102G                   -
zroot/DATA/vtest-16  available             10.2T                  -
zroot/DATA/vtest-16  referenced            101G                   -
zroot/DATA/vtest-16  compressratio         1.00x                  -
zroot/DATA/vtest-16  reservation           none                   default
zroot/DATA/vtest-16  volsize               100G                   local
zroot/DATA/vtest-16  volblocksize          16K                    -
zroot/DATA/vtest-16  checksum              fletcher4              inherited from zroot
zroot/DATA/vtest-16  compression           off                    default
zroot/DATA/vtest-16  readonly              off                    default
zroot/DATA/vtest-16  copies                1                      default
zroot/DATA/vtest-16  refreservation        102G                   local
zroot/DATA/vtest-16  primarycache          all                    default
zroot/DATA/vtest-16  secondarycache        all                    default
zroot/DATA/vtest-16  usedbysnapshots       0                      -
zroot/DATA/vtest-16  usedbydataset         101G                   -
zroot/DATA/vtest-16  usedbychildren        0                      -
zroot/DATA/vtest-16  usedbyrefreservation  886M                   -
zroot/DATA/vtest-16  logbias               latency                default
zroot/DATA/vtest-16  dedup                 off                    default
zroot/DATA/vtest-16  mlslabel                                     -
zroot/DATA/vtest-16  sync                  standard               default
zroot/DATA/vtest-16  refcompressratio      1.00x                  -
zroot/DATA/vtest-16  written               101G                   -
zroot/DATA/vtest-16  logicalused           100G                   -
zroot/DATA/vtest-16  logicalreferenced     100G                   -
root@storage01:~ #
freebsd  zfs  zvol 
— Alex
источник
Мы подозреваем, что это может быть фрагментация, но мы не знаем, как это доказать
— Алекс
Может ли это быть связано со снимками?
— Стив Уиллс
Нет, у нас нет снимков на этом томе
— Алекс
Печально, когда я вижу, что сжатие отключено на томах / файловых системах ZFS. Во всяком случае, вы можете опубликовать zpool status -vи zpool listи zfs list?
— Ewwhite
1
Из всего, что я вижу в этом, это похоже на ошибку. «Используемый» zvol с объемом 100G не должен превышать намного больше 100G, если нет детей, бронирований или чего-то подобного. Возможно, это был объем volsize 200 ГБ, а вы изменили параметр volsize? Если нет, FreeBSD-10.0 еще не является производственной версией; подать ошибку с ними.
— Nex7

Ответы:

2

VOLSIZE представляет тот размер тома, который будет виден клиентам, а не размер тома, хранящегося в пуле.

Эта разница может исходить из нескольких источников:

  • пространство, необходимое для метаданных
  • место, необходимое для хранения нескольких копий (параметры «копии»)
  • «потраченное впустую пространство» из-за заполнения при выравнивании блоков размера «volblocksize» по структуре vdev; Под структурой vdev я подразумеваю два параметра: количество дисков в raidz-N и размер физического блока устройств.

При создании тома ZFS будет оценить , сколько места нужно будет использовать для того , чтобы иметь возможность представить объем «volsize» своим клиентам. Вы можете увидеть это различие в томах vtest-16 и vtest-3 (для которых refreservation составляет 102 ГБ, а volsize - 100 ГБ). Расчет можно найти в libzfs_dataset.c (zvol_volsize_to_reservation (uint64_t volsize, nvlist_t * props))

То, что не учитывается этим расчетом, является третьим источником. Третий источник мало влияет на vdevs, созданные с дисками с 512-байтовыми секторами. Из моих экспериментов (я проверил это, заполнив весь zvol, чтобы проверить это), это действительно имеет значение, когда vdev создается на более новых дисках сектора 4K.

Еще одна вещь, которую я обнаружил в своих экспериментах, заключается в том, что наличие зеркал не показывает различий между расчетным резервированием и тем, что в итоге будет использовано.

Это мои результаты при использовании дисков 4K с томами, которые имеют размер по умолчанию (8 КБ). Первый столбец представляет количество дисков в vdev:

    raidz1  raidz2
3   135%    101%
4   148%    148%
5   162%    181%
6   162%    203%
7   171%    203%
8   171%    217%
9   181%    232%
10  181%    232%
11  181%    232%
12  181%    232%

Это мои результаты при использовании секторных дисков размером 512 байт и размера по умолчанию 8 Кбайт. Первый столбец представляет количество дисков в vdev:

    raidz1  raidz2
3   101%    101%
4   104%    104%
5   101%    113%
6   105%    101%
7   108%    108%
8   110%    114%
9   101%    118%
10  102%    106%
11  103%    108%
12  104%    110%

Мои выводы следующие:

  • Не используйте диски 4K
  • Если вам действительно нужно их использовать, создайте объем, используя размер вольблока больше или равный 32 КБ; Это оказывает незначительное влияние на производительность и незначительное использование пространства (большие размеры блоков требуют меньшего заполнения для правильного выравнивания).
  • Предпочитаю полосы зеркал для ваших бассейнов; Этот макет имеет как преимущества в производительности, так и меньше сюрпризов, связанных с пространством, как этот.
  • Оценка явно неверна для случаев, описанных выше, и это ошибка в zfs.
— Дан Ватка
источник
2
ashift=9Известно, что использование дисков 4k в пуле с проблемами вызывает проблемы. В этом нет ничего нового. Изменение размера блока также не выравнивает диски. Правильное решение - создать пул с ashift=12.
— Крис С
ashift=12на дисках 4K это не разрешается; фактически, на zpool с ashift=125-ю накопителями по 4K и raidz, занимаемое пространство близко к указанному выше, например, объем 7T потребляет 11T.
— Друки
-1

Если я правильно logicalreferencedпонял , у вас есть 87,6 ГБ данных на томе. Номер 170 ГБ, который вы просматриваете, - это объем физического пространства, используемого данными. Так что, если у вас есть зеркальные диски, я ожидаю, referencedчто будет примерно в 2 раза logicalreferenced.

— длинная шея
источник
Хм, другая FS в том же пуле имеет, referenced 3.50Gи logicalreferenced 3.00Gпоэтому соотношение 2x не согласовано среди FS в пуле.
— Алекс
И, кстати, бассейн raidz2, а не простое зеркало
— Алекс
Я только что провел несколько быстрых тестов на ВМ, и моя теория не оправдалась.
— longneck
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.