Continuando o exposto na primeira parte deste tutorial (bom, vou chama-lo assim agora) em http://meumaravilhosomundolivre.blogspot.com.br/2014/06/zfs-no-debian-jessie-testing.html, partimos para a resolucao de alguns inconvenientes encontrados ao compilar e instalar o ZFS a partir do repositorio git.Notei que, depois de criado um sistema de arquivos de tamanho fixo, o dispositivo de bloco correspondente nao era criado.Criar o sistema de arquivos com tamanho fixo e verificar a existencia do dispositivo de bloco correspondente:zfs create mypool01/data -V 10Gls -al /dev/zvol/mypool01/datals: nao e possivel acessar /dev/zvol/mypool01/data: Arquivo ou diretorio nao encontrado O problema e que nem mesmo /dev/zvol existia, entao eis os passos para contornar isto.Copiar os arquivos udev para o local correto:cp /usr/lib/udev/rules.d/60-zvol.rules /etc/udev/rules.dcp /usr/lib/udev/rules.d/69-vdev.rules /etc/udev/rules.dCriar o arquivo /etc/default/zfs com o conteudo:ZFS_MOUNT=yesZFS_UNMOUNT=yesZFS_SHARE=noConfirmar a execucao do script /etc/init.d/zfs-mount na inicializacao padrao:update-rc.d zfs-mount defaultsFoi importante que o script zfs-mount rodasse na inicializacao para que nao fosse necessario rodar um simples "zpool status" para que o dispositivo de bloco correspondentes ao sistema de arquivos mypool01/data aparecesse logo apos o sistema carregado. Minimum Required Driver Version2.24.00.32Windows 2008 x86 http://www.dell.com/support/home/br/pt/brbsdt1/Drivers/DriversDetails?driverId=CW1N9http://downloads.dell.com/FOLDER00353674M/1/SAS-RAID_Driver_CW1N9_WN32_2.24.0.32_A03.EXE Se a execucao do rsync esta lhe causando arrepios com a mensagem "cannot delete non-empty directory" quando se esta utilizando --delete para que o que e excluido na origem seja refletido no destino, pode ser que esteja acontecendo o mesmo que mim.Inicialmente meu rsync era assim:rsync -avh --delete E entao alterei para isto:rsync -avh --exclude=Thumbs.db --delete Acabou acontecendo de muitos arquivos Thumbs.db continuarem no destino e o --delete nao observa que eles foram excluidos na origem, porque eles continuam la. Entao o que temos a fazer e --delete-excluded, para que estes arquivos que estao na origem, mas foram filtrados, e nao queremos que eles continuem no destino, porque ficaram la por uma alteracao de politica de rsync:rsync -avh --delete-excluded --exclude=Thumbs.db --delete Acabei de implementar o inComum 0.3.3 em conjunto com o squid 2.7 em debian squeeze amd64 (virtualizado em kvm em debian squeeze amd64 :-P ).Conto detalhes na sequencia. Temos um storage que pensei em dar uma incrementada e prover uma solucao de backup e preservacao de dados utilizando ZFS. A ideia foi "por que nao criar um pool ZFS em um volume do storage e entregar um ZVOL atraves de iscsi para uso, seja pelo servidor de arquivos ou XenServer?"Como nao posso atualizar o sistema operacional do storage, para isto precisaria de um host intermediario com duas interfaces de rede, uma ligada ao storage, outra para o initiator.Neste host intermediario instalei o novissimo Debian Jessie (https://www.debian.org/CD/http-ftp/#stable) e ZoL (http://zfsonlinux.org/debian.html).Instalei os pacotes open-iscsi e iscsitarget. Depois disto foi so alterar alguns arquivos de configuracao.Logo depois de instalado o open-iscsi e antes dos comandos iscsiadm para descoberta de luns, alterei o arquivo /etc/iscsi/iscsid.conf, substituindo a linha "node.startup = manual" por "node.startup = automatic".Com o advento do systemd, tive que fazer muita experimentacao ate conseguir fazer com que a ordem de execucao dos daemons open-iscsi, zfs e iscsitarget ocorressem exatamente nesta ordem:1o open-iscsi para conexao a lun do storage;2o zfs para importacao do pool criado e descrito em /etc/zfs/zpool.cache;3o iscsitarget para disponibilizar volumes iscsi para outros initiators a partir de dispositivos ZFS, os ZVOLs.Eis