 |
gildot |
 |
| |
| | |  | Contribuído por BladeRunner em 18-01-02 14:35
do departamento kernel-bugs | |  | |  | | |  daniel escreve "Vivam! Apos ver este link página já não me sinto tão sozinho numa longa batalha em torno da estabilidade do Linux com o kernel 2.4 (+ XFS no meu caso, mas nao penso estar relacionado). Vinha saber das opinioes e experiencia do resto das pessoas. Nada de "desktops" please, aqui a questao é mesmo de servidores (com SMP, para começar) que levam porrada a sério, all around the clock, que é como quem diz, 24/7 (não quero dizer que um desktop não possa ser "stressado", mas percebem onde quero chegar). Eu tive o azar de "receber" máquinas com MB ASUS CUV SMP (Chipset IDE da Via que é reconhecidamente "buguento" mas é também tremendamente popular, pelos vistos), mas as queixas não ficam só por ai. Atenção que o autor do artigo (tal como eu) defende o Linux at all costs, mas é apenas uma questao de kernel 2.2 vs. 2.4 em que a sua conclusão é a seguinte: The kernel of pain Let's call a spade a spade: For large servers, the 2.4 kernel has been a disaster.
Abraços,
Daniel Fonseca " | | | | | | < Estude na UA | HP desiste de fabricar PCs! > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Viva!
Eu tive problemas com o 2.4 / XFS, mas nunca cheguei a saber de quem era a culpa.
Algumas versões do 2.4 não fazem correctamente o umount das partições no shutdown das máquinas e outra coisa que já pude verificar é que discos IDE têm performances *completamente* distintas nalgumas versões do 2.4
Agora não posso comprovar isso com números, mas tinha um IDE que dava 8 / sec. com uma versão e 30 com outra, por exemplo. Isto com os mesmos parâmetros no hdparm.
Alguma razão devem ter os tipos da Debian ao irem lançar a Woody com 2.2
Mário Gamito
"Make everything as simple as possible... but not simpler"
Albert Einstein |
| | | | No artigo kernel 2.5.2 vinha uma referência a esse artigo e uma breve discussão de alguns utilizadores do gildot.
|
| | | | | | Pois... quando submeti, nao tinha seguido essa thread (eu sou daqueles que em vez de ir para as threads que nao me interessam, dizer que nao deviam lá estar, prefiro ignorar) - o artigo vinha num mail com o tenebroso subject "Why the 2.4 kernel is a disaster | LinuxWorld.com".
A discussão que lá está é válida, mas mais uma vez, o on-topic desta thread é mesmo sobre levar os servidores a correr 2.4 ao extremo e já eliminei o factor XFS da equação. Eu tenho ficado completamente envergonhado com os problemas que me têm acontecido por já ter muita experiência e estar habituado a estes problemas como sendo apenas do hardware, o que não me parece ser o caso. Ja fiz de tudo, passar as memórias pelo memtest86, etc, etc e os problemas de falta de estabilidade continuam, under very high load.
No Desktop não são de esperar tantos problemas à partida, felizmente, mas o Linux sempre foi about the servers!
Respondendo ao Gamito: a performance é boa (hdparm's de 20 / 30 MB/seg) em tudo, o problema são os "mysterious hangs" e/ou reboots.
Abraços,
Daniel Fonseca |
| | | | Estou a usar o 2.2 num servidor e tenho precisamente esses problemas.E sei que não é de hardware.
Não faço ideia do que seja :/
|
| | | | Eu tenho estado a usar kernels 2.4 em servidores de produção e os unicos problemas que tive foram de hardware. Algumas das maquinas tem XFS, e tem funcionado bem. Zero problemas ate' agora. Tive alguns problemas com o RedHat 7.1 numas maquinas IBM, mas a mesma versao noutras maquinas nao davam problemas.
Depois de fazer o upgrade para o RedHat 7.2 descobri no suporte da IBM que tinha que fazer o upgrade ao firmware da maquina que aquilo era um problema conhecido. Como o RedHat 7.2 resolveu, ainda esta' assim e ate' hoje nao teve mais problemas.
Agora nao uso chipsets Via em nenhuma. Tudo Intel, a maior parte sao i815, excepto as IBMs que são .. IBMs :)
|
| | | por Anonimo Cobarde em 18-01-02 17:32 GMT (#3)
|
| Eu sei que não tem havido grandes noticias, mas meus caros editores, deixem de repetir topicos de discussão por favor.
Obrigado!
|
| | | | Uma coisa que referem no artigo, e que muita gente no Slashdot confirmou, é que os problemas "visíveis" de estabilidade do 2.4.x parecem estar resolvidos no 2.4.17.
Será que foi por ter passado do Linus para o Marcelo?
"Prepare to be seduced by my Psycho-Power!"
- M. Bison, Street Fighter Alpha 3 |
| | | | Posso estar a falar muito sem experiencia real, pois nao tenho nenhum servidor com o 2.4 ainda, mas...
esquecam os kernels 2.4.x com x<=16
se as distros veem com um kernel cheios de patchs para tentar estabilizar os velhos 2.4.x (x numero baixo), nao ha' nada como o 2.4.17
no meu 486 (que atinge os limites com facilidade) os 2.4. sempre tiveram alguns problemas, mas com o ultimo ele voltou quase a estabilidade do 2.2 (digo quase pois o X ja' me crashou varias vezes, mas desconfio do X 4.1.0 ou de um problema do meu WM actual ,fluxbox)
uma coisa e' certa, se o linus teve de se manter no 2.4 ate' ao 2.4.16, entao era porque havia problemas graves ate' esse ponto, logo tentar usar esses kernels antigos, mesmo com patchs, e' correr com um pneu remendado
o 2.4 demorou mais tempo que o 2.2 a estabilizar, mas com mais algumas iteracoes ele ira' ficar tao estavel como o 2.2, pois a velhice nos kernels do linux e' sinonimo de estabilidade.
Higuita |
| | | | | | Concordo em geral, mas vejo a a parte do Linus mais ou menos ao contrário: o problema foi mesmo ele ter ficado a manter o 2.4.x.
O próprio Linus já disse muitas vezes que faz isto "por piada", e que não é um bom maintainer para kerneis (isto diz-se??) estáveis.
Já agora, o 2.4.9 da Red Hat (ou Mandrake) não tem NADA a ver com o 2.4.9 de base. A Red Hat tem há muito o seu próprio "branch" do kernel. Vejam como é feito um SRPM e divirtam-se...
"Prepare to be seduced by my Psycho-Power!"
- M. Bison, Street Fighter Alpha 3 |
| | | | | Concordo em geral, mas vejo a a parte do Linus mais ou menos ao contrário: o problema foi mesmo ele ter ficado a manter o 2.4.x. O próprio Linus já disse muitas vezes que faz isto "por piada", e que não é um bom maintainer para kerneis (isto diz-se??) estáveis. De alguma forma concordo com as tuas afirmacoes. Ate' porque sensivelmente a partir do momento ke a `pasta' da tree 2.4 for entregue ao Marcelo Tosatti, a estabilidade do kernel subiu consideravelmente. Isto porque, sabendo-se que o Marcelo e' realmente competente, e' especialmente conservador nos patches ke aplica e isso a medio prazo vai tendo as suas compensacoes. So' nao concordo totalmente quando dizes que o mal esta' no Linus fazer isto 'por piada'. Nem tanto ao mar nem tanto ah terra :) A grande parte dos gurus do kernel fazem isto por piada.. mas nao e' aquele tipo de piada que leva um projecto a desordenar-se. Acima de tudo entendo pessoalmente que o Linux ganha imensamente mais com o Linus a cargo de uma tree devel do que a cargo de uma tree stable. Os genios nao devem estar presos 'a manutencao de coisas que se querem estaveis. Devem, isso sim, andar com isto cada vez mais para a frente 8) Regards, // Paulo Andre'
|
| | | | o problema foi mesmo ele ter ficado a manter o 2.4.x.
ele teve de ficar com ele... por duas razoes:
-a de sempre, ficar uns tempos para o pessoal auditar mais o novo kernel e nao passar logo para o unstable seguinte
-havia problemas de estabilidade, especialmente em grande carga, usava o swap demais (tornando o computador mais pesado), alem dos problemas mais simples... mas o maior problema era mesmo o VM existemte (nao que fosse ma', mas tinha problemas)
andaram uns tempos a tentar corrigir esses problemas, mas talvez por desentendimento entre o criador da VM antiga e o linus nao se estava a resolver bem as coisas e quando apareceu a nova VM o linus resolveu cortar o mal pela raiz e trocar-la a meio do 2.4, arrastando a situacao por mais tempo
e claro, como ele esta habituado a aceitar as coisas interessantes que vao aparecendo, foi incluindo no 2.4 tudo que ai aparecendo, levando ao aparecimento de mais bugs
mas isso nao invalida que antes do 2.4.10, com a VM antiga, existissem varios problemas graves, e que entre o 2.4.10 a 2.4.16 nao houvessem outros problemas graves (e como a VM era diferente, problemas era diferentes)
lembra-te que assim que foi resolvido o ultimo problema grave da VM nova, o linus passou o kernel, coisa que nao podia fazer antes pois se ele saisse para o 2.5 iriam com ele as pessoas que poderiam ajudar a resolver o problema
ja' agora este ultimo problema era (julgo eu) uma situacao de grande carga num servidor de topo com oracle
julgo que a VM antiga se portava melhor com carga excessiva que a nova (ie: ficava menos lento devido a um swap mais agressivo mas inteligente), mas isso nao quer dizer que a nova crash hoje em dia com a carga
o linus nao ficou com o 2.4 tanto tempo por prazer, pelo contrario... mas a necessidade assim o abrigou
Já agora, o 2.4.9 da Red Hat (ou Mandrake) não tem NADA a ver com o 2.4.9 de base. A Red Hat tem há muito o seu próprio "branch" do kernel.
nada mais e' o 2.4.9 com todos os patchs para corrigir os bugs que existiam nesses kernels... e sao uma data de patchs
o que prova que esses kernels tinham varios problemas, e muito podem ainda existir (senao essa kernel nao era mais do que o 2.4.17 com um nome diferente)
se existisse o 2.4.18 e eles fizessem um kernel para a distro, provavelmente apenas levaria 2 ou 3 patchs, todos como extras (tipo o patch das quotas, drivers novos, XFS, etc) e nenhum de correcao de bugs
Higuita |
| | | | Ahh... que saudades do patches da VA ... :-)
Um dos kerneis (?) mais estaveis q encontrei ainda foi o 2.2.18-VA1 :-)
--
Trespassers will be shot. Survivors will be shot again.
|
| | | | Não sei como é possível considerarem usar um OS cujo kernel só traz problemas até à 16a "bugfix" microsoftiana ( tem sempre + uns pós :) em máquinas de produção...
Se o usarem, por favor, da próxima esperem até ao 2.6.20, por causa das dúvidas.. :-]
hununu, LTI-DEQ@IST, Portugal |
| | | | Se queres ter uma maquina para serviços criticos SMP 24 horas por dia, a solução é não por Linux nem Intel (talvez os xeons ou itanium). Passa por outras Soluções proprietárias como Solaris ou AIX ou HP-UX.
Se tems servidores Intel e queres fiabilidade tems outras alternativas sem ser Linux, tais como FreeBSD ou OpenBSD que pela minha experiencia são mais estaveis que Linux (principalmente a série 2.4.x).
Caso sejas fanatico só por Linux ou tenhas serviços que precisem dele, só tems uma alternativa, 2.2.x se não tiveres mais do que 4 gigas de ram. Deves encontrar mais RH 6.2 em servidores criticos do que RH 7.2 podes apostar. Se quiseres soluções mais prime-time ainda como HA-clustering a maior parte das soluções nem suporte tem para o 2.4.x ainda.
|
| | | | | | Tsk.
Ou entao encontras uma distro que te agrade, patchas a dita cuja de forma a ficar estavel q.b. e passas a usa-la.
E' um das maravilhas do open source ... nao tens que ficar agarrado a nada :-)
--
Trespassers will be shot. Survivors will be shot again.
|
| | | | Era apenas uma provocação. Pessoalmente tenho-me dado muito bem com BSD depois de ter brincado com várias distros de linux.
Não me arrependo, mas não critico quem use linux, longe disso. Tem pontos muito fortes e está no caminho para "low-end" desktop users (perdoem-me a expressão :) Se o caminho está a ser o melhor, isso já deixo para cada um pensar :)
No entanto choca-me ver que ate' ao 2.4.16 as coisas não correram bem.. de facto, até diria que correram muito mal e imagino o que seria o windows2k sair com este tipo de erros ! ( Nem tudo é mau pelos lados microsoft, especialmente com a séria 2k. Nem tudo é bom, longe disso!)
Agora, alguem falou em patches... imagina que ao 2.4.10 instalaste-o em 50 máquinas de produção, ou digamos 10 ou 20 (sejamos realistas talvez..) já viste o trabalho e o patching que tens q fazer ? Não sei como com a 2.4.10 consegues corrigir 'a pata erros q se descobriram até ao 2.4.16. Se consegues, acho que o mundo agradece que partilhes ;)
hununu, LTI-DEQ@IST, Portugal |
| |
|
