Voltando...
Datacom - Tavares wrote:
On Sat, 2005-10-29 at 08:57 -0200, Marcos Lazarini wrote:
Datacom - Tavares wrote:
CLARO QUE NAO! Praticamente qualquer FS eh fragmentado, uns mais outros
menos.. Soh nao se fragmentam os implementados para nao se
fragmentarem :)
O local do arquivo tem importancia no desempenho. Algumas aplicacoes
especificas, algumas maquinas dedicadas ou embarcadas possuem esse
requisito. Já li sobre os filesystems do linux darem suporte a isso..
filesystems do seculo passado. Hoje a unica garantia que voce tem é que
um arquivo vai estar dentro da partição. Concordo quando diz que o local
do arquivo faz diferença, mas se quiser que um arquvio fique por volta
de uma região no HD, faça uma nova partição lá e grave seu arquivo lá
dentro.
No windows, há sim importância da disposição física dos arquivos no HD,
já que o filesystem é tonto e faz uma besteira atras da outra; se a
gente não toma cuidado, a fragmentação fica tamanha q nem o próprio
defrag do win2k/xp funciona mais!
No linux, faz tempo que esse problema foi resolvido e não temos mais que
esquentar a cabeça com detalhes assim.
Nao entendi o que voce quis dizer com filesystems do seculo passado.. A
que estas te referenciando?
5 ou 6 anos atrás as opções de filesystens eram mínimas, se não eram apenas
o ext2. Desde então, os sistemas evoluiram bastante e incorporaram vários
recursos e capacidades extras.
O ext2/3 ainda possui na sua configuracao as opcoes de "Fragment size" e
"Fragments per group" que servem para tuning de fragmentacao.. Ele ainda
se fragmenta, e nao eh pouco :)
Voce pode ver isso de dois jeitos: ele te dá liberdade e permite você
escolher, ou você tem que escolher porque ele não consegue resolver sozinho
qual o melhor.
Nesse caso, eu prefiro ter um problema a menos pra me preocupar...
O ext2/3 tende a escrever arquivos em sequencia no disco, a partir do
inicio dele..
Nao sou um expert no assunto, mas acredito que tem como colocar um
arquivo em um determinado local numa particao e seta-la como RO para que
o arquivo nao saia mais de lah.
Se isso fosse importante e valesse a pena, poderiamos achar tutoriais de
como fazer isso, até no guia foca. Acho que não é o caso.
Ou melhor, com o atributo "i" no arquivo (immutable), tu podes garantir
que o arquivo ficarah quieto e intocado..
Eu li sobre esse atributo 'i' mas acho que só os BSDs que implementam. No
linux ficou pro futuro... se é que vai existir.
No ext2 existem parametros de configuracao para que ele tente colocar os
arquivos de forma continua.. Isso eh configuravel..
Meu amigo, qual filesystem decente não tenta fazer isso por default? Não
vale FAT e NTFS... :-)
E outra coisa, só usa ext2 hoje quem formatou a partição a ultima vez
faz mais de 5 anos... Bom, talvez usuários de flashdrives, mas ai a
aplicação não é mais em HD.
Veja bem, o linux mexe (realoca) nos arquivos previamente guardados no
disco para que os novos fiquem de forma continua. Isso nao acontece no
windows com FAT e NTFS.. O parametro pra tuning que citei acima eh o
responsavel por isso, acho que nao tinhas entendido o que estava
querendo dizer..
Bom, isso eu não confirmo nem nego, mas é plausível. Só não sei o quanto
isso iria afetar a performance do sistema, sem mencionar o risco de perder
mais informação do que gostaria (se na hora que ele está abrindo espaco pra
gravar algo e o processo não termina? Nessa hora vc tem dois arquivos pela
metade e não apenas um)
Bom, eu soh uso ext2 por algumas razoes:
- Nao preciso me preocupar com journaling e as cacas que podem acontecer
com o FS devido a eu ter, em algum espaco de tempo, um jornal diferente
do estado do FS.
- Minha maquina nao dah crash.. Raramente ocorre.. Nao preciso do
jornal..
- Jornal eh otimo para recuperacoes rapidas sem ter que verificar o
disco todo, nao eh o meu caso.. Quando isso acontece, prefiro esperar e
nao me preocupar..
- Com jornal o desempenho cai.. Como nao preciso de jornal, posso ter
mais desempenho.. :)
- E o principal motivo: uso nobreak e o linux congela 1x a cada 3 meses
numa maquina que fica up 24hs por dia e que eu executo todo tipo de
coisa nela.. :)
Nao preciso de journaling.. :)
- Ah, posso usar write cache! Ganho mais em desempenho sem perigo de ter
um jornal diferente do estado do FS caso haja um crash.. (write cache e
jornal eh uma das coisas mais perigosas que existe!) :)
Vc menciona várias vezes inconsistência do jornal com o FS. Nunca vi isso
acontecer, com o write-cache off. Isso só acontece no caso do hibernate?
Agora, depois de todas as reinstalações e os paus causados pelo rompimento
do delicado equilibro em que o ext2 vive (que presenciei), não fico nem um
pouco seguro guardando meus dados em partições ext2, por mais no-break e
bateria que eu tivesse...
Tipo /home em reiser, xfs, etc.
o resto pode mandar qquer coisa, depois eu uso o rsync pra restaurar o
backup ;-)
- Ah, experimente usar jornal em um notebook que costumar hibernar (meu
caso com meu notebook!).. Se tiveres um erro durante a hibernacao
(raro!) o estado do jornal vai estar inconsistente se comparado ao
estado do FS..
Isso eu nao sei dizer, mas tenho um amigo que tem um laptop com
suspend-to-disk funcionando a um bom tempo e nunca reclamou de nada...
Vc há de concordar que essa de sugerir o unison foi só pra aumentar o
'flame'; pra que usar um programa canhão c/ interface gráfica pra
resolver um problema que voce mesmo resolveria usando uma linha do dd?
Tem uma thread minha congelada aqui na lista sobre backup usando dd..
procure por ela..
Na verdade, eu criei toda uma estrategia para backup com o dd e
simplesmente nao funcionou por causa de algum motivo mistico..
Não acredito em coisas 'místicas' na computação. O que causa esse efeito na
maioria das vezes é HW defeituoso. Não tem como vc fazer um programa que,
num if, uma hora executa o then, outra o else - a condição tá sempre bem
determinada e pode ser repetida.
Se um problema de SW parece intermitente, é que a verdadeira 'condição do
if' não foi descoberta ainda.
Vou dar uma sugestão lá, talvez vc já tenha tentando...
Tenho usado o Unison para algumas coisas e cheguei a conclusao de que a
melhor estrategia de backup eh utiliza-lo.. Eh realmente resolvi partir
para backup em nivel de arquivos..
Irei proceder com mais posts na outra thread nos proximos dias..
[...]
Essa eh a principal diferenca de alguem da fisica na computacao e de
alguem com a bagagem e graduacao em ciencia da computacao..
Jah observei isso algumas vezes em outros locais e no "mundo real"..
Puro preconceito e dor-de-cotovelo... :-)
Já vi vários engenheiros elétricos melhores programadores que muitos
cientistas da computação por ai; isso não é um argumento nem ponto de
discussão.
Ai eh que estah! Ser programador nao quer dizer nada.. Qualquer guri no
2o. grau pode ser um bom programador e manjar tudo de java ou php ou
qualquer linguagem baba. E principalmente sao eles mesmos que
implementam sistemas com erros grotescos devido a nao conhecerem as
teorias de sistemas operacionais, redes de computadores, bancos de
dados, etc ..
Eu já penso que o que falta são bons testes na etapa de desenvolvimento e
uma boa política de programação. Se todos conhecessem SO, redes, etc seria
ótimo, mas dá pra fazer um bom serviço se uma parte conhecer e fizer o
trabalho dela.
Mas já estamos ficando muito [OT] por aqui...
A questao nao estah em programar e sim desenvolver um algoritmo livre de
falhas.. Pensar!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
