> > Message: 5 > Date: Tue, 21 May 2013 19:38:26 -0300 > From: Marcelo Gondim <gon...@bsdinfo.com.br> > Subject: Re: [FUG-BR] ALTQ + Intel Drivers. > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > <freebsd@fug.com.br> > Message-ID: <519bf762.5030...@bsdinfo.com.br> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Em 21/05/13 18:14, Renato Botelho escreveu: > > On 05/21/2013 04:52 PM, Bruno Araújo wrote: > >> Em 21/05/2013, às 16:32, Renato Botelho <rbga...@gmail.com> escreveu: > >> > >>> On 05/21/2013 04:28 PM, Marcelo Gondim wrote: > >>>> Em 21/05/13 15:52, Renato Botelho escreveu: > >>>>> On 05/21/2013 02:57 PM, vic wrote: > >>>>>> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu: > >>>>>>> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100% > !! > >>>>>>> mas > >>>>>>> ele ainda é experimental e as panes são normais. > >>>>>>> > >>>>>>> isso tá bem documentado. > >>>>>>> > >>>>>>> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que > >>>>>>> escreve :p) > >>>>>>> > >>>>>> Sim, é experimental, mas eu tenho usado com sucesso o vimage. > Contudo > >>>>>> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o > >>>>>> virtualbox por exemplo). > >>>>>> > >>>>>> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último > >>>>>> compilado mas não está em uso) e está funcionando à 128 dias sem > parar e > >>>>>> com 7 jails. > >>>>> Ah sim, o fato de ser experimental não quer dizer que absolutamente > não > >>>>> irá funcionar. Serve mais pra te alertar que pode dar problema, que > não > >>>>> é estável. > >>>>> > >>>>> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD > 9.1 > >>>>> não está estável, sendo que ele optou por usar algo experimental. > Quando > >>>>> você faz essa escolha está sujeito as consequências :) > >>>>> > >>>>> []s > >>>> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava > >>>> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa > data > >>>> o bug. O uso do ntfs com leitura e escrita também dava um monte de > >>>> kernel panic. Não sei agora como está. > >>> OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por > >>> conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do > >>> kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF. > >>> > >>>> Teve kernel panic que descobri também no geom mas esse foi corrigido > >>>> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer > >>>> dump no /var/crash. Esse problema do crash vi alguns relatos também, > que > >>>> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só > uma > >>>> preocupação que estou tendo. Todos os meus servidores em produção > estão > >>>> rodando muito bem e sem reboots. > >>>> Meu medo é termos algo que aconteceu na versão 5.0, que eu não > >>>> vivenciei, mas que muitos tiveram problemas. > >>> Esses crashs estranhos e sem explicação são coisas que têm que ser > >>> diagnosticadas, e em muitos casos no final o problema tá no hardware. > >>> Sugiro habilitar debugs no kernel e ver se consegue algo. > >>> > >>> Sobre o que aconteceu no 5.0, foi uma história bem diferente, e > acredito > >>> que o time aprendeu com o erro, uma versão com tantas mudanças como > >>> ocorreu do 4 pro 5 não deve acontecer mais. > >>> > >> Quando um mero pacote ou software derruba o S.O. não é uma falha grave > do S.O? > > Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de > > kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo > > falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os > bugs. > > > Opa Renato, > > Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era > um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à > copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente > devia estar usando esse cara porque o panic era instantâneo mesmo. Bem > esse foi resolvido rápido. > Agora esse race condition que é brabo porque ele está lá em algum lugar > e tipo não posso colocar um server e pendurar 4000 assinantes nele > sabendo que se alguém na minha rede fizer um ataque de login incorreto > por um certo tempo, vai causar um kernel panic derrubando os meus 4000 > assinantes. Eu fiz uma atualização ontem no sistema e parece que não > ocorreu mais mas ainda quero testar mais e ter certeza. > Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o > que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só > tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado. > > Grande abraço à todos > > > > Bom pessoal, já que o tópico mudou de ALTQ + INTEL para FreeBSD estabilidade, gostaria de compartilhar meu ponto de vista quanto ao 9.1-RELEASE.
Estou trabalhando há mais de 1 ano em um produto que usa FreeBSD como base. FreeBSD é ótimo, robusto e etc; como todos sabem. Agora vamos para o lado ruim, e esse lado ruim é realmente ruim mesmo. 1) Multirouting table e routing. - FIB não funciona bem no FreeBSD, tive que fazer várias alterações para fazer o FIB funcionar sem ter que iniciar daemons com setfib! Como eu expliquei em outro email; quero que o tráfego que entra via ix0 saia via ix0 independente da rota que tiver para a subrede na tabela FIB 0. No LINUX isso funciona a séculos. - Tive que modificar muita coisa para fazer isso funcionar, ficou lindo; não submeti de volta para o FreeBSD por 2 motivos: 1.1) NDA na empresa onde trabalho; até que bem conversadinho eles liberam. 1.2) O desenvolvimento do FreeBSD é lento, especialmente no "SRC", pessoal muito ocupado, existência de grupinhos e etc. NOTA: Um patch que enviei em 2008 para o IPFW, foi comitado alguns meses atrás. 2) Routing. - O código responsável pelo roteamento no FreeBSD é uma bagunça, não funciona direito e é cheio de bugs. Praticamente uma caixa de pandora, pedaços de código em tudo quanto é canto, mal documentado e etc. - Ninguém ou quase ninguém tem coragem de abrir/tocar na "caixa de pandora". 3) Intel Drivers. - As vezes no site da INTEL o driver é mais novo que no FreeBSD, e no FreeBSD temos 4 desenvolvedores da INTEL e um deles trabalha diretamente nos drivers de rede INTEL. - Depois que eu enviei um patch com a atualização do driver ixgbe, o desenvolvedor meio que deu risada, dizendo que ele é o mantenedor do driver e que eu não precisava enviar a atualização. Minha resposta foi: -- Então atualiza na base porra. Outros desenvolvedores também reclamaram sobre esse problema do driver antigo na base. No final o driver foi atualizado no CURRENT e no 9-STABLE. PATCH: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/176281 4) Alguém sabe como o radix_mpath funciona? "EU SEI!". - Não existe documentação para o radix_mpath, tive que ler o código para entender como funciona. E detalhe que, não funciona como deveria, mas para MULTIPLES ROUTING and ROUTING FAIL OVER or ROUTING LOAD BALANCE ele funciona bem. 5) ALTQ. - É uma vergonha não ter uma API genérica para que os drivers de rede usem o ALTQ. - IXGBE e GBE estão quebrados no 9.x por conta da falta de uma API, foram atualizados os drivers e várias chamadas do ALTQ foram removidas e agora são incompatíveis, pois esses novos drivers usam MULTIPLES QUEUES. 6) PCIe(Non-Transparent-Bridge). - Foi inserido algumas semanas atrás esse driver pela INTEL, estou em contato com eles há quase 1 ano, tentando ajudar, oferecendo código e etc. Resultado, meu driver já está pronto há mais de 8 meses e eu uso DMA ao contrário de usar memcpy() como eles(sabem que é errado) estão fazendo. 7) Apenas como curiosidade. Vocês sabiam que "ifconfig <iface> 192.168.1.1/24" é errado? O que eu quero dizer é que, para configurar um endereço IPv4, nós deveriamos fazer desta forma "ifconfig <iface> inet 192.18.1.1/24", mas não fazemos por conta de um bug que introduziu esta opção para nós sem ter que usar "inet" e isso também quebrou um monte de coisa ou forçou muita gente a fazer um monte de gambiarra em outras partes de código, especialmente na parte de roteamento. FreeBSD é bom? Sim, ele é! É uma maravilha? Não, nem fodendo! Abrir bug report e enviar patches resolve? Bom, prefiro não entrar em detalhes!! """Porém, continuem enviando patches, abrindo bug reports, enviando emails direto para os maintainers, isso ajuda bastante!!""" Eu vou morrer defendendo o FreeBSD, enviando patches, desenvolvendo, fazendo o possível para melhorar o SO! Mas o FreeBSD não é aquela maravilha, e mais do que nunca está precisando de "CARNE FRESCA" para o time de desenvolvimento. Abraços. -- Marcelo Araujo ara...@freebsd.org ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
