LINUX.ORG.RU
Форум — General  

Слишком маленькая скорость записи на raid-z

 


3

3

Привет.
С неприятным удивлением для себя обнаружил такую картину на своем сервере: 

smd@jupiter:/tank/work/smd/riscv/images$ sudo dd if=new_fedora_image.img of=/dev/zvol/tank/vm/riscv_vm_3
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 693.554 s, 11.5 MB/s
Поясню, что тут происходит: у меня собран raid-z массив и на базе того же zfs есть тома, которые будут отданы виртуалкам в качестве фс. И, пока ничего не запущено, я с этого рейд массива ддшу на него же 8гб имеджа диска.
Казалось бы, последовательный доступ, скорость должна быть +- нормальная, но нет. Увы, не имею представления, куда копать.
Во время копирования по iostat картинка какая-то такая: 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.18    0.00   21.70    2.39    0.00   67.73

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda              0.00    1.00      0.00      9.00     0.00     1.80   0.00  64.29    0.00    6.60   0.00     0.00     9.00   0.00   0.00
sdb              0.00    1.00      0.00      9.00     0.00     1.80   0.00  64.29    0.00   16.40   0.00     0.00     9.00   0.00   0.00
md0              0.00    2.20      0.00      8.80     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     4.00   0.00   0.00
md1              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
md2              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
sdc            437.00   83.60   2311.20    556.00     0.00     0.00   0.00   0.00    1.57    0.42   0.54     5.29     6.65   0.46  23.76
sdd            436.40   89.00   2374.40    573.60     0.00     0.00   0.00   0.00    1.65    0.33   0.52     5.44     6.44   0.45  23.44
sde            441.80   97.20   2306.40    577.60     0.20     0.00   0.05   0.00    1.31    0.24   0.50     5.22     5.94   0.40  21.76
zd0           1988.80 10326.60   7955.20  41306.40     0.00     0.00   0.00   0.00    0.04    0.71   7.39     4.00     4.00   0.03  31.44
zd16          2008.60    0.00   8034.40      0.00     0.00     0.00   0.00   0.00    0.04    0.00   0.08     4.00     0.00   0.04   8.08
zd32             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd48             0.00  705.40      0.00   2821.60     0.00     0.00   0.00   0.00    0.00    0.23   0.16     0.00     4.00   0.01   0.80
zd64             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd80             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.64    0.00   14.46    0.89    0.00   72.02

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda              0.00    4.80      0.00     17.20     0.00     0.40   0.00   7.69    0.00    2.71   0.00     0.00     3.58   0.17   0.08
sdb              0.00    4.80      0.00     17.20     0.00     0.40   0.00   7.69    0.00    4.92   0.00     0.00     3.58   0.17   0.08
md0              0.00    4.20      0.00     16.80     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     4.00   0.00   0.00
md1              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
md2              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
sdc            664.60   28.40   3924.00   1828.00     0.00     0.00   0.00   0.00    0.91    1.22   0.51     5.90    64.37   0.34  23.76
sdd            680.20   33.40   3883.20   1836.80     0.00     0.20   0.00   0.60    0.99    1.05   0.52     5.71    54.99   0.35  25.04
sde            708.60   52.60   3795.20   1818.40     0.00     0.00   0.00   0.00    0.67    0.42   0.38     5.36    34.57   0.24  18.48
zd0           2514.20    0.00  10056.80      0.00     0.00     0.00   0.00   0.00    0.04    0.00   0.11     4.00     0.00   0.04  10.72
zd16          2581.60    0.00  10326.40      0.00     0.00     0.00   0.00   0.00    0.04    0.00   0.09     4.00     0.00   0.04   9.44
zd32             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd48            28.40    0.00    113.60      0.00     0.00     0.00   0.00   0.00    2.03    0.00   0.06     4.00     0.00   2.03   5.76
zd64             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd80             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

smd@jupiter:/tank/work/dev/images/riscv$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 7h6m with 0 errors on Sun Mar 10 07:30:58 2019
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K0FU2HCS  ONLINE       0     0     0
            ata-ST2000NM0033-9ZM175_Z1X02J9D          ONLINE       0     0     0
            ata-ST2000NM0033-9ZM175_Z1Y01BZC          ONLINE       0     0     0

errors: No known data errors

smd@jupiter:/tank/work/dev/images/riscv$ sudo zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.44T  3.34T  2.10T         -    25%    61%  1.00x  ONLINE  -

smd@jupiter:/tank/work/dev/images/riscv$ sudo zfs get all tank | grep -v default
NAME  PROPERTY              VALUE                  SOURCE
tank  type                  filesystem             -
tank  creation              Wed Feb  5 21:06 2014  -
tank  used                  2.22T                  -
tank  available             1.28T                  -
tank  referenced            2.21T                  -
tank  compressratio         1.01x                  -
tank  mounted               yes                    -
tank  recordsize            16K                    local
tank  mountpoint            /tank                  local
tank  compression           lz4                    local
tank  atime                 off                    local
tank  createtxg             1                      -
tank  xattr                 sa                     local
tank  version               5                      -
tank  utf8only              off                    -
tank  normalization         none                   -
tank  casesensitivity       sensitive              -
tank  guid                  8135613722416036316    -
tank  usedbysnapshots       0B                     -
tank  usedbydataset         2.21T                  -
tank  usedbychildren        18.3G                  -
tank  usedbyrefreservation  0B                     -
tank  refcompressratio      1.01x                  -
tank  written               2.21T                  -
tank  logicalused           2.22T                  -
tank  logicalreferenced     2.20T                  -
tank  acltype               posixacl               local

md@jupiter:/tank/work/dev/images/riscv$ sudo zfs get all tank/vm/riscv_vm_3 | grep -v default
[sudo] password for smd: 
NAME                PROPERTY              VALUE                  SOURCE
tank/vm/riscv_vm_3  type                  volume                 -
tank/vm/riscv_vm_3  creation              Sat Mar 30 17:24 2019  -
tank/vm/riscv_vm_3  used                  2.48G                  -
tank/vm/riscv_vm_3  available             1.28T                  -
tank/vm/riscv_vm_3  referenced            2.48G                  -
tank/vm/riscv_vm_3  compressratio         1.36x                  -
tank/vm/riscv_vm_3  volsize               10G                    local
tank/vm/riscv_vm_3  compression           on                     inherited from tank/vm
tank/vm/riscv_vm_3  createtxg             29871336               -
tank/vm/riscv_vm_3  guid                  1236530763382609933    -
tank/vm/riscv_vm_3  usedbysnapshots       0B                     -
tank/vm/riscv_vm_3  usedbydataset         2.48G                  -
tank/vm/riscv_vm_3  usedbychildren        0B                     -
tank/vm/riscv_vm_3  usedbyrefreservation  0B                     -
tank/vm/riscv_vm_3  dedup                 off                    inherited from tank/vm
tank/vm/riscv_vm_3  refcompressratio      1.36x                  -
tank/vm/riscv_vm_3  written               2.48G                  -
tank/vm/riscv_vm_3  logicalused           2.53G                  -
tank/vm/riscv_vm_3  logicalreferenced     2.53G                  -
Железка, на которой все крутится: tyan S8226.
Прошу помощи у экспертного сообщества, тк не понимаю, во что оно упирается и куда/как копать: Dimez, King_Carlo, vxzvxz

Deleted

Последнее исправление: SMD (всего исправлений: 4)
← OneFileLinux - не получается собрать
Почему top, atop не показывают все процессы, сильно нагружающие CPU →

  1 2 3
Ответ на: комментарий от Deleted 
/dev/sde1        2048 7814019071 7814017024  3.7T Solaris /usr & Apple ZFS
/dev/sde9  7814019072 7814035455      16384    8M Solaris reserved 1

Это естественное поведение при скармливании диска целиком. ZFS само создаёт GPT-таблицу и резервирует восемь мегабайт (но я даже не интересовался для чего).

начала разделов выровнены на 2048

Units: sectors of 1 * 512 = 512 bytes

2048/512, 4K.

Как это можно обеспечить кроме как выставлением volblocksize?

Никак, ashift можно указать только при создании пула. И вообще не заморачивайся, у тебя выравнено на 4K. Напейся и забудь.

Если сильно тормозит, посмотри на:

zpool get fragmentation tank
mord0d ★★★★★
()
Ответ на: комментарий от mord0d

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

Deleted
()
Ответ на: комментарий от iron

Это я только завтра смогу попробовать, сегодня сервак забит был. Но обязательно попробую и отпишусь.

Deleted
()
Ответ на: комментарий от mord0d

У него изначально был raid-z, потом умер диск, массив упал в degraded, он заменил диск, сделал resilvering. Так что всё нормально.

anonymous
()

Welcome to ZFS. Короче выход либо добавлять cache device с SSD (а лучше как минимум два). Или перебираться на BTRFS, где дешево бюджетно, скорость предсказуемая для любой помойки и не нужно разбираться в настройке. Ну или дальшь есть что дают и смериться.
Ну как же не зайти и не ... в теме про ZFS, правда ведь?

anonymous_sama ★★★★★
()
Ответ на: комментарий от anonymous_sama

Если нужно вынести ZIL на отдельный раздел, то попробовать можно сделав на разделе ext4 файл 

mkdir /ZIL
dd if=/dev/zero of=/ZIL/zil_disk.img bs=1M count=4096
zpool add tank log /ZIL/zil_disk.img
Увидите, помогло ли. Потом можете удалить и поместить на SSD Но ИМХО проблема у него с чтением мелкими блоками. Замонтируй пул по NFS и проверь чтение и запись - увидишь, что скорость как минимум в 2-2.5 раза вырвстет

anonymous
()
Ответ на: комментарий от mord0d

Анонимус, отписавшийся ниже, правильно описал случившееся. Возможно, я использовал не совсем удачные термины при описании.

Deleted
()
Ответ на: комментарий от iron

Делюсь результатами: 

smd@jupiter:~$ sudo zpool list
[sudo] password for smd:
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.44T  3.35T  2.09T         -    25%    61%  1.00x  DEGRADED  -
smd@jupiter:~$ sudo zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: resilvered 48K in 0h0m with 0 errors on Mon Apr  1 09:56:49 2019
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          DEGRADED     0     0     0
          raidz1-0                                    DEGRADED     0     0     0
            ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K0FU2HCS  OFFLINE      0     0     0
            ata-ST2000NM0033-9ZM175_Z1X02J9D          ONLINE       0     0     0
            ata-ST2000NM0033-9ZM175_Z1Y01BZC          ONLINE       0     0     0
Т.е. остались 2 диска с 512 размером сектора.
Положил образ, который ддшу сразу в раму, чтобы исключить проблемы с чтением. Получил такие результаты. 
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=512 conv=sync status=progress
7971684864 bytes (8.0 GB, 7.4 GiB) copied, 181 s, 44.0 MB/s
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 187.808 s, 42.6 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=4096 conv=sync status=progress
7992082432 bytes (8.0 GB, 7.4 GiB) copied, 11 s, 727 MB/s
1952768+0 records in
1952768+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 67.2872 s, 119 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=512 conv=sync status=progress
7988429312 bytes (8.0 GB, 7.4 GiB) copied, 171 s, 46.7 MB/s
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 175.99 s, 45.4 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=4097 conv=sync status=progress
7987486618 bytes (8.0 GB, 7.4 GiB) copied, 133 s, 60.1 MB/s
1952291+1 records in
1952292+0 records out
7998540324 bytes (8.0 GB, 7.4 GiB) copied, 139.584 s, 57.3 MB/s
Хочу заметить, что в случае с бс=4096, данные сначала кешируются, т.е. дд репортит скорости по 800мбс, но в итоге оно падает до 112мбс, что норм.
В случае с бс=512, скорость записи, которую репортит дд, с самого начала держится на ~45мбс, т.е. кеширования не происходит.
Похожая ситуация с отстутсвием кеширования и у варианта с бс=4097, только изначальная скорость, которую репортит дд повыше, около 70мбс и плавно падает до 45-50.
Я, все же, окончательно не могу понять, это косяк зфс, которая криво настроена, или же дискам капут?
Наверное, самым лучшим вариантом в моем случае будет купить 2 таких же диска, как тот вд на 4тб и за 2 раза перевести весь массив на них. Это позволит мне, как минимум, иметь возможность сохранить данные на освободившиеся диски и при необходимости поэкспериментировать с raid-z, пересоздав его.

Deleted
()
Ответ на: комментарий от anonymous

потом умер диск, массив упал в degraded, он заменил диск, сделал resilvering

Видимо, я это прощёлкал. Я тред читал по-диагонали.

mord0d ★★★★★
()
Ответ на: комментарий от anonymous_sama

BTRFS

На проде? УПРЛС?

дешево бюджетно

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

Я не любитель RAIDZ, как наследника RAID-5/RAID-6, но уж лучше использовать их, чем Btrfs.

mord0d ★★★★★
()
Ответ на: комментарий от Deleted

Это не кэш на SSD, а лог на отдельном разделе - ZIL Кэш на SSD - это secondarycache

anonymous
()

Как говорит один хороший человек, friends do not let friends use raid-z. raid-z хорошо там, где большие блоки и потоковое чтение. Для виртуалок - плохой выбор. Без логзиллы - вообще ужасный. Не делай так.

anonymous
()
Ответ на: комментарий от Deleted

Так я и предполагал. Скорее всего у тебя проблема с выравниванием по размеру физ. блока, так как без 4k диска скорость, как для raidz с 512 блоком, становится в норме. Попробуй пересоздать пул на дисках без разметки, должно помочь. Как минимум 4k диск не будет замедлять пул.

Наверное, самым лучшим вариантом в моем случае будет купить 2 таких же диска, как тот вд на 4тб и за 2 раза перевести весь массив на них. Это позволит мне, как минимум, иметь возможность сохранить данные на освободившиеся диски и при необходимости поэкспериментировать с raid-z, пересоздав его.

Разумное решение.

iron ★★★★★
()
Ответ на: комментарий от iron

Меня смущает скорость в 45мбс, тк слишком уж мало. Или нет?
Сейчас забекаплю данные, какие смогу, и попробую все заребилдить с нуля.

Deleted
()
Последнее исправление: SMD (всего исправлений: 1)
Ответ на: комментарий от iron

На сырое чтение свмого диска через они 180мбс выдают. Как забекаплюсь, попробую их нулями позабивать.

Deleted
()
Ответ на: комментарий от iron

На всякий случай уточню, что необходимо сделать(и не делать), чтобы избежать таких проблем в будущем?
Вайпнуть партиции, забить диски нулями, создать raid-z массив из голых дисков с record size 16k, ashift 12, после чего сделаю zvol том, на котором поставлю volblocksize в 4к и проверю скорость, так?

Deleted
()
Ответ на: комментарий от Deleted

Просто оставлю тут 

# zfs get all zfs/tst
NAME     PROPERTY              VALUE                                       SOURCE
zfs/tst  type                  filesystem                                  -
zfs/tst  creation              Mon Apr  1 14:46 2019                       -
zfs/tst  recordsize            128K                                        local
zfs/tst  mountpoint            /zfs/tst                                    default
zfs/tst  compression           lz4                                         inherited from zfs
zfs/tst  atime                 off                                         inherited from zfs
zfs/tst  xattr                 sa                                          inherited from zfs
zfs/tst  primarycache          all                                         default
zfs/tst  secondarycache        none                                        inherited from zfs
zfs/tst  usedbysnapshots       0B                                          -
zfs/tst  usedbydataset         507M                                        -
zfs/tst  usedbychildren        0B                                          -
zfs/tst  usedbyrefreservation  0B                                          -
zfs/tst  logbias               throughput                                  local
zfs/tst  dedup                 off                                         default
zfs/tst  mlslabel              none                                        default
zfs/tst  acltype               off                                         default
zfs/tst  redundant_metadata    most                                        inherited from zfs
zfs/tst  overlay               off                                         default

anonymous
()
Ответ на: комментарий от anonymous 
# service nfs status
 rpc.svcgssd is stopped
 rpc.mountd is stopped
 nfsd is stopped
 rpc.rquotad is stopped

# service nfs start
 Starting NFS services:                                     [  OK  ]
 Starting NFS quotas:                                       [  OK  ]
 Starting NFS mountd:                                       [  OK  ]
 Starting NFS daemon:                                       [  OK  ]

# zfs set sharenfs='rw=@*,anonuid=1000,anongid=1001,all_squash' zfs/tst

# ls /mnt

монтируем через localhost пул в /mnt
# mount localhost:/zfs/tst /mnt -o rw,hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600

раздел ext4
# ls -la /tmp/1
...
 -rw-r-----  1 oracle dba  4194312192 Apr  1 14:44 data.dat
...

# dd if=data.dat of=/dev/null
8192016+0 records in
8192016+0 records out
4194312192 bytes (4.2 GB) copied, 13.2967 s, 315 MB/s

Проверяем запись в пул
копируем прямо в созданный пул zfs/tst
# dd if=data.dat of=/zfs/tst/data1.dd bs=512
8192016+0 records in
8192016+0 records out
4194312192 bytes (4.2 GB) copied, 69.3636 s, 60.5 MB/s

а это туда же, но через NFS
# dd if=data.dat of=/mnt/data2.dd bs=512
8192016+0 records in
8192016+0 records out
4194312192 bytes (4.2 GB) copied, 24.5867 s, 171 MB/s

опять в пул
# dd if=data.dat of=/zfs/tst/data1.dd bs=512
8192016+0 records in
8192016+0 records out
4194312192 bytes (4.2 GB) copied, 72.9784 s, 57.5 MB/s

опять через NFS
# dd if=data.dat of=/mnt/data2.dd bs=512
8192016+0 records in
8192016+0 records out
4194312192 bytes (4.2 GB) copied, 24.5452 s, 171 MB/s

Я думаю видна разница

anonymous
()
Ответ на: комментарий от anonymous

Спасибо, сейчас попробую и этот вариант.

Deleted
()
Ответ на: комментарий от Deleted

Пересобрал массив на имеющихся дисках так: 

zpool create -f -o ashift=12 tank raidz1 disk0 disk1 disk2
smd@jupiter:~$ sudo zfs get all tank
[sudo] password for smd:
NAME  PROPERTY              VALUE                  SOURCE
tank  type                  filesystem             -
tank  creation              Mon Apr  1 16:54 2019  -
tank  used                  2.90G                  -
tank  available             3.51T                  -
tank  referenced            128K                   -
tank  compressratio         1.08x                  -
tank  mounted               yes                    -
tank  quota                 none                   default
tank  reservation           none                   default
tank  recordsize            16K                    local
tank  mountpoint            /tank                  default
tank  sharenfs              off                    default
tank  checksum              on                     default
tank  compression           lz4                    local
tank  atime                 off                    local
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  createtxg             1                      -
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  guid                  8142248022266041350    -
tank  primarycache          all                    local
tank  secondarycache        all                    default
tank  usedbysnapshots       0B                     -
tank  usedbydataset         128K                   -
tank  usedbychildren        2.90G                  -
tank  usedbyrefreservation  0B                     -
tank  logbias               latency                default
tank  dedup                 off                    local
tank  mlslabel              none                   default
tank  sync                  standard               default
tank  dnodesize             legacy                 default
tank  refcompressratio      1.00x                  -
tank  written               128K                   -
tank  logicalused           2.36G                  -
tank  logicalreferenced     40K                    -
tank  volmode               default                default
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              off                    default
tank  redundant_metadata    all                    default
tank  overlay               off                    default
smd@jupiter:~$ sudo zfs create -s -V 10g -o volblocksize=4K  tank/rv_image_1
smd@jupiter:~$ sudo zfs get all tank/rv_image_1
NAME             PROPERTY              VALUE                  SOURCE
tank/rv_image_1  type                  volume                 -
tank/rv_image_1  creation              Mon Apr  1 17:04 2019  -
tank/rv_image_1  used                  2.90G                  -
tank/rv_image_1  available             3.51T                  -
tank/rv_image_1  referenced            2.90G                  -
tank/rv_image_1  compressratio         1.08x                  -
tank/rv_image_1  reservation           none                   default
tank/rv_image_1  volsize               10G                    local
tank/rv_image_1  volblocksize          4K                     -
tank/rv_image_1  checksum              on                     default
tank/rv_image_1  compression           lz4                    inherited from tank
tank/rv_image_1  readonly              off                    default
tank/rv_image_1  createtxg             129                    -
tank/rv_image_1  copies                1                      default
tank/rv_image_1  refreservation        none                   default
tank/rv_image_1  guid                  13851968559415427498   -
tank/rv_image_1  primarycache          all                    inherited from tank
tank/rv_image_1  secondarycache        all                    default
tank/rv_image_1  usedbysnapshots       0B                     -
tank/rv_image_1  usedbydataset         2.90G                  -
tank/rv_image_1  usedbychildren        0B                     -
tank/rv_image_1  usedbyrefreservation  0B                     -
tank/rv_image_1  logbias               latency                default
tank/rv_image_1  dedup                 off                    inherited from tank
tank/rv_image_1  mlslabel              none                   default
tank/rv_image_1  sync                  standard               default
tank/rv_image_1  refcompressratio      1.08x                  -
tank/rv_image_1  written               2.90G                  -
tank/rv_image_1  logicalused           2.36G                  -
tank/rv_image_1  logicalreferenced     2.36G                  -
tank/rv_image_1  volmode               default                default
tank/rv_image_1  snapshot_limit        none                   default
tank/rv_image_1  snapshot_count        none                   default
tank/rv_image_1  snapdev               hidden                 default
tank/rv_image_1  context               none                   default
tank/rv_image_1  fscontext             none                   default
tank/rv_image_1  defcontext            none                   default
tank/rv_image_1  rootcontext           none                   default
tank/rv_image_1  redundant_metadata    all                    default
Меряем скорость: 
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/rv_image_1 conv=sync status=progress  bs=4096
7880495104 bytes (7.9 GB, 7.3 GiB) copied, 10 s, 788 MB/s
1952768+0 records in
1952768+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 60.1513 s, 133 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/rv_image_1 conv=sync status=progress  bs=512
7943864832 bytes (7.9 GB, 7.4 GiB) copied, 170 s, 46.7 MB/s
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 175.86 s, 45.5 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora32_image_jdk_ready.img of=/dev/zvol/tank/rv_image_1 conv=sync status=progress  bs=4097
7936651042 bytes (7.9 GB, 7.4 GiB) copied, 133 s, 59.7 MB/s
1952291+1 records in
1952292+0 records out
7998540324 bytes (8.0 GB, 7.4 GiB) copied, 137.965 s, 58.0 MB/s
И снова видим ту же картину, но чуть лучше.

Deleted
()
Ответ на: комментарий от anonymous

Я пока сломался на моменте маунта зфс, как нфс шары: 

smd@jupiter:~$ sudo mount localhost:/tank/ /media/ -o rw,hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600
mount.nfs: requested NFS version or transport protocol is not supported
smd@jupiter:~$ sudo mount localhost:/tank/ /media/ -t nfs4 -o rw,hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600
mount.nfs4: requested NFS version or transport protocol is not supported
smd@jupiter:~$ sudo mount localhost:/tank/ /media/ -t nfs4 -o rw,hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600 --verbose
mount.nfs4: timeout set for Mon Apr  1 19:02:02 2019
mount.nfs4: trying text-based options 'hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600,vers=4.2,addr=::1,clientaddr=::1'
mount.nfs4: mount(2): Connection refused
mount.nfs4: trying text-based options 'hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600,vers=4.2,addr=127.0.0.1,clientaddr=127.0.0.1'
mount.nfs4: mount(2): Connection refused
mount.nfs4: trying text-based options 'hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600,addr=::1'
mount.nfs4: prog 100003, trying vers=3, prot=6
mount.nfs4: portmap query retrying: RPC: Program not registered
mount.nfs4: prog 100003, trying vers=3, prot=17
mount.nfs4: portmap query failed: RPC: Program not registered
mount.nfs4: trying text-based options 'hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600,addr=127.0.0.1'
mount.nfs4: prog 100003, trying vers=3, prot=6
mount.nfs4: portmap query retrying: RPC: Program not registered
mount.nfs4: prog 100003, trying vers=3, prot=17
mount.nfs4: portmap query failed: RPC: Program not registered
mount.nfs4: requested NFS version or transport protocol is not supported

Deleted
()
Ответ на: комментарий от Deleted

Отключи компрессию, чексуммы, поиграйся с размером страйпа или как там называется записываемый блок, распределямый по (всем?) дискам в raidz. Уменьши метаданные, например, отключив xattrs, acl.

anonymous
()
Ответ на: комментарий от Deleted

sudo zpool get all | grep ashift

Внушает. Но я могу круче: sudo zpool get all | cat | cat | cat | grep ashift

anonymous
()
Ответ на: комментарий от Deleted

zpool create -f -o ashift=12 tank raidz1 disk0 disk1 disk2
zfs create -s -V 10g -o volblocksize=4K tank/rv_image_1

Поздравляю! В итоге все блоки твоего тома будут занимать 8К каждый , то есть как в зеркале, но читать готовые к употреблению данные можно будет только с одного из них. С другого - только если первый накроется и только с вычислением данных после чтения содержимого диска.

Сказано же тебе - плохая это конфигурация. Не делай так. Возьми еще один диск и сделай два зеркала в пуле. Ну и еще маленький SSD для логзиллы.

anonymous
()
Ответ на: комментарий от Deleted

На всякий случай уточню, что необходимо сделать(и не делать), чтобы избежать таких проблем в будущем?

  • постараться не юзать raidz. Уж лучше RAID 0+1 или 1+0 (взависимости куда нужен уклон: в стаильность или скорость), если конечно количество винтов позволяет. Я бы на твоем месте сделал бы из 512 дисков mirror и забыл raidz как страшный сон.
  • юзать винты одной модели, а еще лучше, одной партии.
  • отдавать под рейд голый девайс не нарезая партишины. При создании пула оно само определяет правильный ashift. По крайней мере в FreeBSD это работает отлично.
  • record size лучше подбирать методом научного тыка. К примеру, создать zvol с 4k блоком и замерять поизводительность внутри виртуалки на реальной нагрузке, не тестом. Потом попробовать 8k и 16k.
  • если высокоинтенсивная нагрузка на запись мелкими блоками, лучше юзать ZIL. Для начала можно сделать ZIL в файлике размещенном в tmpfs, замерять насколько реально он ускоряет операции записи. Потом уже думать о покупке SSD/NvMe для него.
  • как уже написали выше, поотключать все лишние метаданные. Возможно отключение кеширования метаданных даст прирост производительности на твоем ворклоде. Нужно тестить...
  • протестить на твоем ворклоде насколько эффективно работает сжатие, возможно без него будет быстрее.
  • если оперативка и проц позволяют и у тебя там будут виртуалки, возможно есть смысл протестить работу дедупликации. Правда как оно работает в ZoL - хз. Я его и на Фре не юзал.
  • протестить насколько эффективно работают File-Level Prefetch и VDEV cache, возможно на твоем ворклоде они дадут прирост. В FreeBSD есть zfs-stats и zfs-mon которые позволяют мониторить эффективность их работы. Возможно и в линуксе они есть или что-то подобное.
  • для полного счастья можно прикрутить L2ARC. Если планируешь ставить SSD под ZIL, то лучше его разбить на два партишина. 1/4 под ZIL, 3/4 под L2ARC.

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

iron ★★★★★
()
Ответ на: комментарий от iron

Большое спасибо за развернутый ответ, но, похоже основная проблема оказывается вовсе не в зфс: 

smd@jupiter:~$ sudo fdisk -l /dev/sde
Disk /dev/sde: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000NM0033-9ZM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
smd@jupiter:~$ sudo dd if=/dev/shm/fedora_image_ready.img of=/dev/sde status=progress conv=sync bs=512
7957537280 bytes (8.0 GB, 7.4 GiB) copied, 199 s, 40.0 MB/s
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 206.783 s, 38.7 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora_image_ready.img of=/dev/sde status=progress conv=sync bs=4096
7339835392 bytes (7.3 GB, 6.8 GiB) copied, 9 s, 816 MB/s
1952768+0 records in
1952768+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 52.842 s, 151 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora_image_ready.img of=/dev/sde status=progress conv=sync bs=4097
7973540430 bytes (8.0 GB, 7.4 GiB) copied, 182 s, 43.8 MB/s
1952291+1 records in
1952292+0 records out
7998540324 bytes (8.0 GB, 7.4 GiB) copied, 183.992 s, 43.5 MB/s
smd@jupiter:~$ sudo dd if=/dev/shm/fedora_image_ready.img of=/dev/sde status=progress conv=sync bs=40973
7893325531 bytes (7.9 GB, 7.4 GiB) copied, 62 s, 127 MB/s[e
195214+1 records in
195215+0 records out
7998544195 bytes (8.0 GB, 7.4 GiB) copied, 91.9524 s, 87.0 MB/s
Из эксперимента выше я могу сделать вывод, что на данный диск все же можно писать на скорости в 130-150мбс, но почему-то только с блоками, кратными 4096. Та же самая история и с другим диском, который репортит физический блок в 4096.
Т.е. складывается ощущение, что проблема где-то в настройке линуксовой подсистемы кеша(?).
Перетыкание этих трех дисков в другой контроллер результаты не изменило, так что хочу верить, что проблема не в сата контроллере.

Deleted
()
Ответ на: комментарий от anonymous

Поздравляю! В итоге все блоки твоего тома будут занимать 8К каждый , то есть как в зеркале, но читать готовые к употреблению данные можно будет только с одного из них. С другого - только если первый накроется и только с вычислением данных после чтения содержимого диска.

Буду признателен, если раскроешь, почему так происходит для осознания общей картины.
Энивей, я тебя услышал, сделаю 1+0 из 4тб дисков, как только разберусь с проблемой медленной записи на диски.
Спасибо.

Deleted
()
Ответ на: комментарий от andyl

Да, мой факап: забыл, что выключил нфс.

Deleted
()
Ответ на: комментарий от iron

RAID 0+1 или 1+0 (взависимости куда нужен уклон: в стаильность или скорость)

Скорость у них одинаковая.

1/4 под ZIL, 3/4 под L2ARC.

Не надо так делать. Зы сдохни от рака, тот кто придумал гугелькапчу.

anonymous
()
Ответ на: комментарий от Deleted

Приветствую! Если ты хочешь затестить непосредственно запись/чтение на диск с помощью dd то нужно совместно с dd использовать опцию direct: iflag=direct это для чтения, oflag=direct - для записи. Если dd использовать без этой опции, то она будут использовать кэш. Без неё - нет! Для проверки можно смотреть командой free -k как будет юзать память. Кроме того ОС делит общую свободную память между кэш zfs и кэш ОС! Определить как будет распределяться память между кэшами , то что будет брать zfs себе и оставлять для ОС можно с помощью параметра zfs_arc_pc_percent см man.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо, сейчас попробую с директом.
Зфс сейчас полностью снесен, поэтому он не должен оказывать влияния. Да и рамы слишком много.

Deleted
()
Ответ на: комментарий от anonymous

Все равно фигня какая-то: 

smd@jupiter:~$ sudo fdisk -l /dev/sde 
Disk /dev/sde: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000NM0033-9ZM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

smd@jupiter:~$ sudo dd if=/dev/shm/fedora_image_ready.img of=/dev/sde conv=sync oflag=direct  bs=4096
1952768+0 records in
1952768+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 129.86 s, 61.6 MB/s

smd@jupiter:~$ sudo dd if=/dev/shm/fedora_image_ready.img of=/dev/sde conv=sync oflag=direct  bs=512
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 909.616 s, 8.8 MB/s

Deleted
()
Ответ на: комментарий от Deleted

Почему фигня ? Это показывает реальную скорость диска без кэша ОС. Отсюда и нужно плясать. Ещё можно отключить кэш на самих дисках если они имеются.

anonymous
()
Ответ на: комментарий от anonymous

Я не готов поверить, что у дисков из 2014 года или моложе реальная скорость записи на диск вчего 60мбс. Причем, это повторяется как на сигейте(репортит 512 блок) и на вд(4096 блок)

Deleted
()
Ответ на: комментарий от anonymous

Это показывает реальную скорость диска без кэша ОС

Это показывает фигню. Ты бы ещё сказал, что реальная скорость видеокарты измеряется glxgears.

anonymous
()
Ответ на: комментарий от anonymous

ну да может с выражением «реальную скорость диска» малость перегнул, но всё же это +/- скорость диска. SMD, попробуй потестить диски с помощью fio.

anonymous
()
Ответ на: комментарий от anonymous

Это не реальная скорость диска, а попускная скорость всего канала от dd до диска с учетом задержек по всему стэку. Это сродни тому, как запись большого количества мелких файлов на флэшку.

anonymous
()
Ответ на: комментарий от anonymous

Может быть, но на неё смотреть примерно так же полезно, как смотреть на производительность CPU с выпиленными L1/L2/L3/Ln-кэшами.

anonymous
()
Ответ на: комментарий от iron

постараться не юзать raidz. Уж лучше RAID 0+1 или 1+0 (взависимости куда нужен уклон: в стаильность или скорость), если конечно количество винтов позволяет. Я бы на твоем месте сделал бы из 512 дисков mirror и забыл raidz как страшный сон.

Я бы поставил этот пункт на самое последнее по значимости место. Давно кручу тазики с виртуалками на raidz2, всё ок. ZFS крайне достойно пережила сбойнувшее железо.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Значит смотри чего получилось из сервера в кладовке. В пуле 3 диска wd red 1Тб (nasware 3.0, все одинаковые). ZFS raidz на трёх дисках sd[c,d,e]. Копируем 100Гб (чтобы нивелировать влияние кэша) образ виртуальной машины из файла в zvol, они расположены на одном массиве. Включено сжатие lz4, atime выключен, arc 4Гб, всё остальное по умолчанию. При создании массива ashift=12, zfs-у скармливались raw-диски без какой-либо разметки. Вся эта радость работает на обычной десктопной маме с чипсетом z97 и 32Гб ОЗУ. Фрагментация на момент теста 25%, свободного места 600Гб из 2Тб.


root@zserver:/home/serg# iostat
Linux 4.15.0-46-generic (zserver) 	02.04.2019 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,35    0,01    0,26    0,37    0,00   99,02

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
loop0             0,00         0,00         0,00          5          0
sda               1,15        13,70        19,94    1334441    1941500
sdb               0,28        16,39         0,00    1595733        376
sdc               4,30        50,76        86,29    4943051    8402628
sdd               4,22        51,14        86,28    4979628    8401668
sde               4,19        49,62        86,32    4831596    8405444
sdf               0,34         8,20        78,91     798772    7683984
dm-0              0,11        11,88         0,00    1157201        376
zd0              39,64         0,01       158,55       1048   15439140
[pre/]


root@zserver:/home/serg/zstorage/vm/windows10# dd if=win10.img of=/dev/zstorage/zvol/win10 bs=8192
13107200+0 записей получено
13107200+0 записей отправлено
107374182400 bytes (107 GB, 100 GiB) copied, 2146,17 s, 50,0 MB/s
King_Carlo ★★★★★
()
Ответ на: комментарий от Deleted

Поздравляю! В итоге все блоки твоего тома будут занимать 8К каждый , то есть как в зеркале, но читать готовые к употреблению данные можно будет только с одного из них. С другого - только если первый накроется и только с вычислением данных после чтения содержимого диска.

Буду признателен, если раскроешь, почему так происходит для осознания общей картины.

Да я уже пытался этой личинке кота объяснить, но, видимо, не в коня корм. Можешь там посмотреть. Если в двух словах - то в RAID-Z каждый логический блок - сам себе страйп.

Энивей, я тебя услышал, сделаю 1+0 из 4тб дисков, как только разберусь с проблемой медленной записи на диски.

Ладно, раз услышал, то попробую еще раз написать, когда время будет, с примерами из zdb.

ЗЫ. Капча мастдай

anonymous
()
Ответ на: комментарий от anonymous

Для эксперимента нам потребуются три диска с размером сектора 4К. Можно, конечно, сделать пул только из файлов, но к файлам понятие размера сектора неприменимо, так что придется их завернуть в блочные устройства. Да, все нижеизложенное делается на Солярке, а в ней этой вашей проперти ashit нету. Повторение эксперимента на ляликсе остаётся в качестве упражнения для заинтересованного читателя.

Итак:

# for i in {1..3} ; do mkfile -n 64M /tmp/disk$i ; done
#
# for i in {1..3} ; do lofiadm -a /tmp/disk$i ; done
/dev/lofi/1
/dev/lofi/2
/dev/lofi/3
#

Три устройства готовы. Настроим размер блока:

# for i in {1..3} ; do lofiadm -x logical-blksize=4096 /dev/lofi/$i; done
# for i in {1..3} ; do lofiadm -x physical-blksize=4096 /dev/lofi/$i ; done
#

Теперь создадим пул и посмотрим, что получилось. Создавать будет пул версии 28 - это последняя совместная версия:

# zpool create -o version=28 pond raidz /dev/lofi/[1-3]
#
# zpool status pond
  pool: pond
 state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
        pool will no longer be accessible on older software versions.
  scan: none requested
config:

        NAME             STATE      READ WRITE CKSUM
        pond             ONLINE        0     0     0
          raidz1-0       ONLINE        0     0     0
            /dev/lofi/1  ONLINE        0     0     0
            /dev/lofi/2  ONLINE        0     0     0
            /dev/lofi/3  ONLINE        0     0     0

errors: No known data errors
#

Красота! Все в лучшем виде. Проверим, правильно ли ZFS определила размер блока:

#
# for i in {1..3} ; do zdb -l /dev/rlofi/$i ; done | grep ashift
        ashift: 12
        ashift: 12
        ashift: 12
#

Все верно.

Самое время создать том с размером блока 4К и сжатием:

# zfs create -V 1M -o volblocksize=4096 -o compression=on pond/vol
#

Готово! Теперь воспользуемся zdb, чтобы посмотреть, что получилось. Данные тома живут в объекте с номером 1:

# zdb -ddddd pond/vol 1
Dataset pond/vol [ZVOL], ID 42, cr_txg 22, 95.9K, 2 objects, rootbp DVA[0]=<0:228000:2000:STD:1> DVA[1]=<0:2428000:2000:STD:1> [L0 DMU objset] fletcher4 lzjb LE unique unencrypted size=800L/200P birth=22L/22P fill=2 contiguous 2-copy cksum=e51d0755f:5c38c7c0ed7:12e17045fbfd6:29f0d83c51e4d7

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
         1    1    16K     4K      0     4K    0.00  zvol object
        dnode flags:
        dnode maxblkid: 0
Indirect blocks:


#

Получилось все в лучшем виде - размер блока этого объекта 4К, размер блока косвенной адресации 16К (этот размер пользователем не регулируется), блоков пока никаких нет, так как мы ничего не писали в наш том.

В принципе, тут можно было бы и остановиться, так как в выводе выше приведен в человекочитаемом виде указатель на блок, которым можно воспользоваться для объяснений. Но мы все-таки не будем останавливаться, а запишем что-нибудь в том в следующем сообщении.

anonymous
()
Ответ на: комментарий от Deleted

Как мы и собирались, давайте все-таки запишем что-нибудь в наш том:

# dd if=/usr/dict/words of=/dev/zvol/rdsk/pond/vol count=1
1+0 records in
1+0 records out
#

Что-нибудь - это файл со словами английского языка, вернее 512 байт из этого файла. Так как 512 значительно меньше 4096, то должно произойти сжатие.

Воспользуемся zdb снова, чтобы посмотреть, что получилось. Но в этот раз воспользуемся дополнительными опциями и скажем zdb, что нужно смотреть не в устройства /dev/lofi/[1-3] (которые прописаны в кэше конфигураций в /etc/zfs/zpool.cache), а непосредственно в файлы, которые обернуты в эти устройства:

# zdb -e -p /tmp/disk1 -p /tmp/disk2 -p /tmp/disk3 -ddddd pond/vol 1
Dataset pond/vol [ZVOL], ID 42, cr_txg 22, 101K, 2 objects, rootbp DVA[0]=<0:412000:2000:STD:1> DVA[1]=<0:260e000:2000:STD:1> [L0 DMU objset] fletcher4 lzjb LE unique unencrypted size=800L/200P birth=73L/73P fill=2 contiguous 2-copy cksum=114911b4c6:6a15a691f37:14ea72602dc6c:2d2ef7a4b245d1

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
         1    1    16K     4K  5.50K     4K  100.00  zvol object
        dnode flags: USED_BYTES
        dnode maxblkid: 0
Indirect blocks:
                 0 L0 0:0x402000:0x2000 0x1000L/0x400P F=1 B=73/73 ---

                segment [000000000000000000, 0x0000000000001000) size    4K

#

Все работает! Что мы видим? Мы видим, что в нашем томе появился 1 блок размером 4К, и мы видим в сокращённом виде указатель на этот блок:

0 L0 0:0x402000:0x2000 0x1000L/0x400P F=1 B=73/73

Что же значат все эти цифры?

Первая - это логическое смещение внутри объекта. Так как мы не указали никакого смещения для dd, она все записала начиная со смещения 0 (записать несколько блоков и посмотреть, что получится, оставляю в качестве домашнего задания). Следующее поле, в котором мы видим L0 - сообщает нам уровень блока в дереве блоков нашего объекта. Поскольку он только один, никаких блоков косвенной адресации нам пока не надо (записать много блоков и посмотреть, что получится - ещё одно домашнее задание).

Следущая поле, а именно три числа, разделённых двоеточиями - это так называемый адрес нашего блока в пуле, как говорят буржуи - DVA или Data Virtual Address. Почему виртуальный? Потому что его нельзя использовать для определения точного физического положения секторов нашего логического блока на дисках нашего пула. Что же означает каждое число? Первое - 0 - это идентификатор устройства верхнего уровня. Поскольку устройство верхнего уровня у нас только одно, то ничего другого, кроме 0 быть и не может (я думаю, вы уже догадались, каково еще одно домашнее задание).

Следующее число - 0x402000 - это смещение от начала нашего виртуального устройства.

Ну и наконец, третье число в троице - это размер выделенного пространства для нашего блока с учетом четности и накладных расходов - именно то число, ради которого вся эта писанина затевалась (aka ASIZE или allocated size). Как мы видим, выделено для нашего блока 8К. Вспоминая, что каждый логический блок сам себе страйп, легко сообразить, что 1 сектор у нас занимают данные, и для защиты этого блока в raidz1 нужен 1 сектор четности, вот и получается, что всего для нашего блока нужно выделить сектора по 4К или 8К всего. Если бы у нас было зеркало, то нам понадобилось бы те же два сектора.

Но это еще не все, но продолжение в следующем сообщении, ибо ЛОР не любит простыни текста.

anonymous
()
Ответ на: комментарий от Deleted

Продолжим. Следующее поле:

0x1000L/0x400P

сообщает нам логический и физический размеры нашего блока (буковка L говорит нам о logical size aka LSIZE, буковка P - о physical size aka PSIZE). Так как физический размер меньше логического, мы можем заключить, что сжатие нашего блока из 512 байт слов английского языка и 3.5К нулей таки произошло, и результат сжатия поместился в 1024 байта (0x400). Помогло ли нам это сэкономить дисковое пространство? Нисколько - так как минимальный выделяемый размер блока в случае raidz составляет 1 сектор для данных и один, два или три сектора для четности для raidz1, raidz2 и raidz3 соответственно. То есть мы потратили ресурсы процессора чтобы сжать, но это не помогло ничего сэкономить. Но это еще не все! По какой-то неведомой причине мы еще и сохранили все это на диске в сжатом виде, чтобы тратить ресурсы процессора каждый раз, когда нам вздумается прочитать этот блок. Думаю, что когда сжатие для ZFS писалось, диски с размером сектора 4К еще не были распространены, поэтому многое вращается вокруг 512-байтного сектора. Кому не лень - можете открыть баг - не думаю, что в OpenZFS ситуация отличается (но буду рад ошибиться).

Самое время задаться вопросом - а что же будет, если мы оставим размер логического блока по умолчанию? Давайте попробуем:

# zfs create -V 1M -o compression=on pond/vol8
#
# dd if=/usr/dict/words of=/dev/zvol/rdsk/pond/vol8 count=16
16+0 records in
16+0 records out
#
# zdb -e -p /tmp/disk1 -p /tmp/disk2 -p /tmp/disk3 -ddddd pond/vol8 1
Dataset pond/vol8 [ZVOL], ID 57, cr_txg 109, 107K, 2 objects, rootbp DVA[0]=<0:832000:2000:STD:1> DVA[1]=<0:2a0e000:2000:STD:1> [L0 DMU objset] fletcher4 lzjb LE unique unencrypted size=800L/200P birth=138L/138P fill=2 contiguous 2-copy cksum=fcaef402a:60c2465e109:130706d298014:28f63b2202e7bf

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
         1    1    16K     8K  10.5K     8K  100.00  zvol object
        dnode flags: USED_BYTES
        dnode maxblkid: 0
Indirect blocks:
                 0 L0 0:0x820000:0x4000 0x2000L/0x1600P F=1 B=138/138 ---

                segment [000000000000000000, 0x0000000000002000) size    8K

#

Что же мы видим? Очень похожую картину. Как и раньше - один логический блок с раземером 8К, как и раньше - он сжался до 0x1600, и мы выделили для него 16К или 4 сектора. «Но как же так?» возмутитесь вы? Ведь если логический блок сам себе страйп, то у нас должно быть 2 сектора для данных и один сектор для четности, которые премиленько бы разместились на 3 дисках нашего raidz1.

Что же это за ерунда-то такая? Об этом - в следующем сообщении, ибо размер сообщений ЛОРа - мастдай еще похуже капчи.

anonymous
()
Ответ на: комментарий от Deleted

Надеюсь, что это последнее.

Тут самое время вспомнить о том, что ASIZE включает в себя не только четность, но и дополнительные накладные расходы, которые этом конкретном случае составляют 4К или один дополнительный сектор. Он возникает от того, что все выделяемые блоки в RAID-Z должны быть кратными минимальному выделяемому размеру - в нашем случае 8К или два сектора. Зачем это нужно? Затем, что мы не хотим оставлять дырки, которые нельзя будет использовать даже для самого маленького блока. Представим себе, что наши три диска имеют всего по три сектора. Последний сектор последнего диска у нас использоваться не будет в силу еще одной особенности ZFS. Итого у нас получится 8 секторов пространства для использования. Изобразим их так (столбцы - это диски, а строки - секторы на этих дисках):

...
...
..

Теперь предположим, что нам надо записать два блока по одному сектору и один блок с двумя секторами. Обозначим их A, B и С, соответственно все сектора блока будем обозначать одной буквой. Пусть C будет большим блоком. Если мы не будем включать в ASIZE сектор накладных расходов, мы можем получить, например, такой расклад:

AAC
CCB
B.

Оставшийся свободный çектор, обозначенный точкой, мы не можем использовать, так как нам нечем его защитить - рядом нет сектора для четности. Предположим, что мы теперь освободили блок С и затем нам понадобилось выделить блок D такого же размера, как и блоки A и B. Мы можем получить такой расклад:

AAD
D.B
B.

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

А теперь, ребятки, поднимите руки те из вас, кто все это и так знал. Надеюсь увидеть целый лес!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3
← OneFileLinux - не получается собрать
General
Почему top, atop не показывают все процессы, сильно нагружающие CPU →