Alexandre Biancalana wrote: > On 8/2/07, Patrick Tracanelli <[EMAIL PROTECTED]> wrote: >> Alexandre, muito bem lembrado. Na verdade acho que é a melhor idéia até >> o momento. >> >> Testei num pequeno servidor, tambem de hosting, com `iostat -w1` >> marcando 1.3MB/s de throughput em disco (producao), deu: >> >> # /usr/bin/time -h mksnap_ffs /usr/home snap01 >> 47.40s real 0.00s user 0.59s sys >> >> O sistema de arquivos nao e grande: >> >> # df -h /usr/home/ >> Filesystem Size Used Avail Capacity Mounted on >> /dev/ad0s1g 83G 25G 57G 30% /usr/home >> >> Mas consideraria aceitavel, da pra fazer um snap a cada 15 minutos, sem >> comprometer o uso em producao (um nice +20 na tarefa agendada ajudaria a >> evitar queda de performance tambem). >> >> Bem pensado =) > > > > Obrigado! ;-) > > Só acho vale a pena ser testado no ambiente final dele, em horário de pico, > em fim, um "teste real", eu nunca usei snapshot desta forma, mas nas listas > la fora teve gente reclamando de "congelamento" momentaneo do SO durante o > snapshot em versões passadas (final do ano passado), e o Kris Kennaway > comentou na época que isso poderia mesmo acontecer.
Sem duvida. Eu tenho problema de congelamento com dump -L por exemplo, em producao. Porem, se o sistema de arquivos nao for muito grande ou o uso em producao tambem nao, muda muito o comportamento. Isso porque o acesso a disco ainda nao pode ser controlado como prioridade no escalonador por exemplo, entao um processo de baixa prioridade pode gerar acesso em disco maior que outros, ao ponto de prejudicar os mais privilegiados. O ideal seria uma forma de definir prioridade de operacao em disco. O PJD comentou sobre estar implementando isso como modulo geom, mas nao sei da "prioridade" disso pra esse desenvolvedor. > Silmar, testa ai e fala pra gente se funcionou, se puder com alguns detalhes > de tamanho do filesystem, tempo de execuçao, etc... Tamanho do FS, metodo de acesso a disco e vazao em producao, vao fazer a diferenca entre a viabilidade ou nao. Senao, implementar na aplicação volta a ser a opcao. > > Eu tenho a idéia de implementar isso nos novos servidores de arquivos aqui > da empresa, pois está cada vez mais frequente os cabecinhas > apagarem/alterarem oque não devem e ficarem pedindo pra restaurar planilhas, > etc... só não testei... teremos pelo menos 2 servidores com 2 TB cada um... Desse tamanho, acho que fora do horario comercial soh. E' servidor de arquivos com o que? Samba tem o vfs recycle que gera a lixeira (com politica configuravel) e appletalk tem o drestore, menos flexivel que o recycle do samba mas ainda assim funcional. Se for NFS, bom, ai so com coisa experimental (NFS4 com o "newnfsd" permite chamar scripts externos pra certos tipos de operacoes). > > Alexandre > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
