[FUG-BR] [1/2 OFF] Erros não detectados em sistemas de arquivos

[Patrick Tracanelli]

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
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"



_______________________________________________
Freebsd mailing list
Freebsd em fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br