Finalmente, encontrei duas soluções.
1) Deixe o ashift no valor padrão, mesmo que os blogs / docs digam o contrário.
2) Aumente o volblocksize para 64K com raidz3.
Eu tenho um armazenamento com o ZFS e o Debian wheezy. Eu estou sempre usando o mais recente ZFS do seu github. Eu criei 3 pools diferentes de raidz-3. Um para cada controlador. Em todos os controladores eu tenho discos 24x 4T SATA. Se eu usar os pools de backup apenas para backups e NFS do Linux, tudo ficará bem. Assim que eu alocar volume para o DPM da Microsoft e Ele está começando a fazer o backup Ele continua comendo todo o espaço em disco que eu tenho em um pool. Como você pode ver abaixo, o volume do bm-backup é de 20 TB, mas está usando muito mais.
Por favor, diga-me como posso limitar os dados usados por um volume? O que eu posso fazer agora? Apenas para destruir e recriar bm-backup? Mas todo mês?
Por favor, me ajude com as configurações / comandos corretos que preciso para manter volumes com o ZFS no linux.
Obrigado.
Você pode ver as informações relevantes abaixo:
uname -a
Linux storage6 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux
Versão do ZFS:
[ 11.200794] ZFS: Loaded module v0.6.3-159_gc944be5, ZFS pool version 5000, ZFS filesystem version 5
[ 10.916233] SPL: Loaded module v0.6.3-52_g52479ec
[ 12.829561] SPL: using hostid 0x00000000
história para armazenamento-02:
2014-12-09.12:58:47 zpool create -m none -o ashift=12 storage-02 raidz3 ...
2014-12-19.11:34:43 zfs create -V 20T storage-02/bm-backup
2014-12-19.11:54:40 zfs set reservation=1T storage-02/bm-backup
lista de zpool:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
storage-02 87T 85.5T 1.47T - 41% 98% 1.00x ONLINE -
storage-03 87T 30.2T 56.8T - 25% 34% 1.00x ONLINE -
storage-81 87T 67.1T 19.9T - 15% 77% 1.00x ONLINE -
zfs get storage-02 / bm-backup:
NAME PROPERTY VALUE SOURCE
storage-02/bm-backup type volume -
storage-02/bm-backup creation Fri Dec 19 11:34 2014 -
storage-02/bm-backup used 64.9T -
storage-02/bm-backup available 88.7G -
storage-02/bm-backup referenced 64.9T -
storage-02/bm-backup compressratio 1.00x -
storage-02/bm-backup reservation 1T local
storage-02/bm-backup volsize 20T local
storage-02/bm-backup volblocksize 8K -
storage-02/bm-backup checksum on default
storage-02/bm-backup compression off default
storage-02/bm-backup readonly off default
storage-02/bm-backup copies 1 default
storage-02/bm-backup refreservation 20.6T local
storage-02/bm-backup primarycache all default
storage-02/bm-backup secondarycache all default
storage-02/bm-backup usedbysnapshots 0 -
storage-02/bm-backup usedbydataset 64.9T -
storage-02/bm-backup usedbychildren 0 -
storage-02/bm-backup usedbyrefreservation 0 -
storage-02/bm-backup logbias latency default
storage-02/bm-backup dedup off default
storage-02/bm-backup mlslabel none default
storage-02/bm-backup sync standard default
storage-02/bm-backup refcompressratio 1.00x -
storage-02/bm-backup written 64.9T -
storage-02/bm-backup logicalused 20.1T -
storage-02/bm-backup logicalreferenced 20.1T -
storage-02/bm-backup snapdev hidden default
storage-02/bm-backup context none default
storage-02/bm-backup fscontext none default
storage-02/bm-backup defcontext none default
storage-02/bm-backup rootcontext none default
storage-02/bm-backup redundant_metadata all default
Finalmente, encontrei duas soluções.
1) Deixe o ashift no valor padrão, mesmo que os blogs / docs digam o contrário.
2) Aumente o volblocksize para 64K com raidz3.