Giovanni P. Tirloni wrote:
> Olá,
>
> Estava lendo a página manual do tune2fs do Linux (calma!) e uma coisa
> me deixou meio intrigado. Nela a opção -c que define o número máximo de
> mountagens que o filesystem pode receber antes de sofrer um fsck forçado.
>
> A justificativa para isso é que problemas com cabos, memoria, discos e
> bugs no kernel poderiam corromper o sistema de arquivos sem que
> necessáriamente ele fosse marcado como sujo (dirty). Forçar um fsck
> depois de um certo número de montagens ajudaria a corrigir isso (se não
> fosse fatal).
>
> Primeira questão: o que acontece com uma máquina que tem um uptime de
> uns 2 anos e onde os sistemas de arquivos foram montados apenas umas 3-4
> vezes nos ultimos 3 anos? Com certeza essa opção não ajuda muito. Por
> dedução eu teria que rebootar meus servidores periodicamente para o fsck
> pegar algum erro escondido que por acaso aparecesse.
>
> Não quero me prolongar muito mas verifiquei que o tunefs do FreeBSD
> não tem essa opção. Talvez porque julguem desnecessária ? É comum esses
> pequenos erros serem introduzidos por acaso devido aos motivos
> mencionados (cabo, memoria, cpu, bugs) sem que seja detectado ?
>
> Pessoalmente nunca tive esse tipo de problema (até onde eu sei, já que
> são erros não-detectados) mas vai lá saber.. Algum guru em FS'es para
> acalmar a mente pensativa? :)
>
> Um abraço,
>
Tirloni,
Como com UFS voce pode montar um FS dirty e depois limpa-lo, mesmo
montado, com COW (Copy On Write) e CL (Clean Live File System), acredito
que o background FSCK resolva isso.
Se voce forca fsck em foreground, com -F (mesmo ele podendo rodar em bg)
se o sistema estiver em multi-user e' feito um snapshot logico, e entao
o fsck e feito nesse snapshot e as correcoes sincronizadas, com COW ou
CL. Isso so' em multiuser.
O detalhe e que nenhuma operacao COW ou CL e' feita enquanto os inodes
dos arquivos estao sendo acessados. Se sao muitos inodes o bgfsck ou
fsck -F mantem a modificacao no snap pendente, e efetivam no FS assim
que o inode e liberado. Ou o FS locka o acesso a esse inode e o efetiva,
se so falta essas pendencias pro fsck sair. Ai existe uma questao que
pode ser dramatica, em discos cheios. Quando voce faz snap os inodes
"fotografados" sao congelados. As modificacoes no mesmo inode e' alocada
com uma marcacao logica, e nao no FS. Se a quantidade de userdata
modificada for muito grande ai sao gravadas nos proximos inodes, e feita
referencia logica a esses inodes, em contrate com os fisicos (no FS). A
questao e que com o disco cheio podem faltar inodes, e os dados que por
ventura sejam apagados onde existe o snapshot nao serao apagados
efetivamente ate que o snap seja destruido. Entao existe um risco
teorico, em particoes em plena atividade (Live) e cheias, de que a
efetivacao de uma correcao destrua userdata ou metadata alocado *apos* o
snapshot. Esse risco e amenizado e sempre que chega-se a esse ponto o
metodo COW e preferido ao inves do CL (mesmo que o CL represente melhor
performance) e o COW passa usar espaco da SWAP. Agora nao lembro se o
espaco da SWAP e usado pras operacoes logicas do snapshot ou as do FS.
Tem um doc do PHK sobre Copy On Write que ajuda a esclarecer isso. Eu li
ele faz tempo e esqueci uma pa dos detalhes =P
Mas entao, na pratica, a equipe por tras da "manutencao programada" pode
tentar diminuir o numero de operacoes de escrita no FS (por exemplo,
desliga o FTP, ou suspende a fila de delivery local de e-mail, ou
suspende INSERTS e UPDATES no banco...) e passar fsck em bg (que
*tambem* faz snapshot, mas nao sei quando nem sob que circunstancias e
dada essa decisao... acho que o doc do McKusick na USENIX me responderia
hehehe) ou em foreground com o FS montado. Dessa forma nao e necessario
qualquer reboot, umount do FS, e ainda evita riscos nas operacoes de W
(apenas se espaco disponivel em disco for um alarmante).
Outra opcao essa manual!:
- mount -o snapshot na particao que voce quer
- desmonta o FS
- monta o snapshot no ponto de montagem do FS
- (agora o mount point em questao acessao snap)
- passa FSCK na device desmontada
Assim nao precisa rebootar. Nunca teste isso! E uma opcao teorica hehe.
Pra melhorar, com GEOM_LABEL e possivel dar-se labels distintos ao mesmo
device e ai monta-los simultaneamente. Ou seja o mesmo dispositivo
fisico montado em pontos diferentes, e com nome de devices diferentes.
Quando isso acontece, existe "lock" de todo inode que esteja em uso em 1
mount-point, e se operacoes paralelas no mesmo inode forem feitas, essa
requsicao e atrasada ate o que o inode seja liberado. Entao, na teoria,
da pra passar FSCK no dispositivo enquanto ele fica montado no label.
Seria uma opcao à abordagem anterior, mas sem SNAPSHOT nessa (e
consequentemente com opcao de W).
Mas o mais facil e contar com o fsck com -B ou -F mesmo! hehuahua, as
outras tem que ser bem testadas antes ;-)
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
[EMAIL PROTECTED]
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
_______________________________________________
Freebsd mailing list
Freebsd@fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br
