ZFS copy on write

Question

Estou planejando usar o ZFS para backups. 5-10 servidores irão "transmitir" atualizações via DRBD para arquivos muito grandes (500 gigabytes cada) no sistema de arquivos ZFS.

Os servidores geram cerca de 20 megabytes por segundo de gravações aleatórias com um total de 100 MBps. Eu não leio esses arquivos, então o padrão deve ser quase 100% escrito.

Para mim, copiar na gravação é uma característica muito importante.

Como eu entendo, a COW deve transformar gravações aleatórias em escritas sequenciais. Mas isso não está acontecendo.

Eu testei em um servidor com 12 drives SAS E5520 XEON (4 core) e 24 GB de RAM e gravação aleatória foi muito baixa.

Eu decidi depurá-lo primeiro em 1 disco rígido SAS no mesmo servidor.

Eu criei o sistema de arquivos EXT4 e fiz alguns testes:

 
root@zfs:/mnt/hdd/test# dd if=/dev/zero of=tempfile bs=1M count=4096 conv=fdatasync,notrunc
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 30.2524 s, 142 MB/s

Então, vejo que a velocidade de gravação é de cerca de 140 MBps.

Aleatório escreve ~ 500 KBps ~ 100-150 iops. O que é normal.

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=1 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
bs: 1 (f=1): [w(1)] [0.6% done] [0KB/548KB/0KB /s] [0/137/0 iops] [eta 02h:02m:57s]

Então, na mesma unidade, criei o ZFS:

zpool crie -f -m / mnt / dados bigdata scsi-35000cca01b370274

Eu configurei o tamanho do registro em 4K porque terei gravações aleatórias em 4K. Tamanho de registro 4K funcionou melhor que 128k quando eu estava testando.

zfs define o registro = 4k bigdata

Gravações aleatórias testadas em arquivos 4G.

fio --randrepeat=1 --ioengine=libaio --gtod_reduce=1 --name=./test --filename=test --bs=4k --iodepth=1 --size=4G --readwrite=randwrite
./test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
./test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/115.9MB/0KB /s] [0/29.7K/0 iops] [
[eta 00m:00s]

Parece que o COW foi bem aqui 115,9 MB por segundo.

Gravações aleatórias testadas em arquivos 16G.

fio --randrepeat=1 --ioengine=libaio --gtod_reduce=1 --name=test --filename=./test16G --bs=4k --iodepth=1 --size=16G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
bs: 1 (f=1): [w(1)] [0.1% done] [0KB/404KB/0KB /s] [0/101/0 iops] [eta 02h:08m:55s]

Resultados muito fracos 400 kilobytes por segundo.

Tentei o mesmo com arquivos 8G:

fio --randrepeat=1 --ioengine=libaio --gtod_reduce=1 --name=test --filename=./test8G --bs=4k --iodepth=1 --size=8G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 8192MB)

bs: 1 (f=1): [w(1)] [14.5% done] [0KB/158.3MB/0KB /s] [0/40.6K/0 iops] [eta 00m:53s]

No começo, o COW estava bem 136 megabytes por segundo.

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               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
sdg               0.00     0.00    0.00 1120.00     0.00   136.65   249.88     9.53    8.51    0.00    8.51   0.89  99.24

Mas no final, quando o teste atingiu 90%, a velocidade de gravação diminuiu para 5 megabytes por segundo.

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               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
sdg               0.00     0.00    0.00  805.90     0.00     5.33    13.54     9.95   12.34    0.00   12.34   1.24 100.00

Então arquivos 4G estão bem, 8G quase bem, mas arquivos 16G não estão recebendo nenhuma COW.

Não entenda o que está acontecendo aqui. Talvez o cache de memória tenha papel aqui.

SO: Debian 8 ZFS ver 500. Nenhuma compactação ou desduplicação.

zpool list
NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
bigdata  1.81T  64.4G  1.75T         -     2%     3%  1.00x  ONLINE  -


root@zfs:/mnt/data/test# zdb
bigdata:
    version: 5000
    name: 'bigdata'
    state: 0
    txg: 4
    pool_guid: 16909063556944448541
    errata: 0
    hostid: 8323329
    hostname: 'zfs'
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 16909063556944448541
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 8547466691663463210
            path: '/dev/disk/by-id/scsi-35000cca01b370274-part1'
            whole_disk: 1
            metaslab_array: 34
            metaslab_shift: 34
            ashift: 9
            asize: 2000384688128
            is_log: 0
            create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data



zpool status bigdata
  pool: bigdata
 state: ONLINE
  scan: none requested
config:

    NAME                      STATE     READ WRITE CKSUM
    bigdata                   ONLINE       0     0     0
      scsi-35000cca01b370274  ONLINE       0     0     0
errors: No known data errors

O

fio não funciona com o O_DIRECT no ZFS Eu tive que executar sem ele. Pelo que entendi, deve produzir resultados ainda melhores. Mas isso não está acontecendo.

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=./test --filename=test16G --bs=4k --iodepth=1 --size=16G --readwrite=randwrite
./test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.11
Starting 1 process
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT