+ Responder ao Tópico



  1. #1
    cag
    Visitante

    Padrão queda de energia, fsck.ext3

    Ocorreu uma queda de energia, utilizei o fsck.ext3 para reparar os erros.

    Rebootei a máquina, depois não encontrou mais erros.
    O Sistema rodou normal mas...

    Estou achando que está demorando para copiar ou apagar arquivos.

    O HD é da samsung, não sei se é paranoia minha, mas uma máquina bem mais antiga com menos memória, apaga ou criar o cache do squid muito rápido.

    Já essa levou alguns segundos.

    Para copiar uma base de 65mb, para o /tmp, também levou um certo tempo.

  2. #2

    Padrão Re: queda de energia, fsck.ext3

    pra vc nao ficar encucado manda ai um, se acaso vc ja fez isso desconsidere a minha ideia !!!

    fsck /dev/hdaX /mnt/extX


    Valeu !!!

  3. #3
    Avenger
    Visitante

    Padrão queda de energia, fsck.ext3

    Talvez você esteja com ATA100 desativado. Me parece que para ativar, às vezes você precisa fazer manualmente (ou colocar no rc.local) o comando: hdparm -d 1 /dev/hda

    Em alguns casos é preciso colocar uma opção no lilo para assumir a IDE como 66MHz (isso ajuda um pouco também -- ou permite usar o ATA-100).

    Para ver se o ATA-100 está ativado é:
    hdparm -d /dev/hda

    Outra coisa que deixa cópia muuito lenta é SWAP em pleno uso... Dá boot na máquina e já digita free, se estiver usando SWAP já ao dar boot, é péssimo sinal. Dá uma olhada também se ele continua lendo o HD mesmo depois que você para de fazer qquer coisa no linux, e digita também uptime prá ver se o uso está alto (acima de 1.0)

    Espero que ajude! :P

  4. #4
    vfsmount
    Visitante

    Padrão queda de energia, fsck.ext3

    Ola

    seguinte, nao sei se vai resolver o problema, mas é possivel ter caido a energia e resetado sua bios, verifique se as configuracoes estao ok, tipo data e hora, se ta reconhecendo os hds automatico e na hora do reconhecimento se ele esta em 32 bits.

    pode ser que o 32 bits esteja em off, troque para on (isso vale para muitas placas mae, porém essas bios que tem o menu suspenso reconhecem 32bits do hd automatico)
    habilite tambem o SMART no setup, se tiver com problemas no hd ele avisa logo na inicializacao e voce tem que pressionar F1 para ligar o micro.

    Talvez dê certo, nao sei se é esse o seu problema.

    Valew

  5. #5
    cag
    Visitante

    Padrão queda de energia, fsck.ext3

    Eu olhei um tópico aqui esses tempos "P4 não reboota".
    Minha placa mãe é o mesmo modelo.

    Não está usando a swap, a máquina está ligada 20 dias, o load está 0 também.

    Estou remotamente, verificar com fsck não é meio arriscado ?

    Outra coisa, quanto ao reconhecimento do hd em 32 bits, tem como verificar remotamente ?

    Muito Obrigado pelas respostas.

  6. #6
    Visitante

    Padrão queda de energia, fsck.ext3

    Dá uma olhada no comando 'hdparm'. man hdparm ou hdparm --help podem ajudar com o comando. Este dá informações sobre discos instalados, talvez dê a informação do acesso 32bit, bem como o do ATA100 que te falei.

  7. #7
    augusto_jdl
    Visitante

    Padrão queda de energia, fsck.ext3

    Pra confirmar se o sistemas de arquivos está ok, rode:

    fsck -Ay

    depois configure o hdparm como mostrado acima por nossos colegas.

  8. #8
    cag
    Visitante

    Padrão queda de energia, fsck.ext3

    Não tem esse comando hdparm, minha distro é TSL,baseada no rh8.

    Quanto a verificacao do fsck, removamente eu tenho um certo medo.
    Vai que da algum pau...

  9. #9
    z3d
    Visitante

    Padrão queda de energia, fsck.ext3

    hdparm -c3 /dev/hdX
    Habilita o modo de 32 bits c/ sincronia
    um simples hdparm -c devolve o status da I/O da IDE qto a acesso de 32 bits.

  10. #10
    cag
    Visitante

    Padrão queda de energia, fsck.ext3

    n tenho esse comando

  11. #11
    Avenger
    Visitante

    Padrão queda de energia, fsck.ext3

    Então, por não ter o hdparm, seu HD deve estar funcionando como ATA66 ou ATA33, com taxa de transferencia de apenas 33MB/s quando poderia estar a 100 ou 133MB/s. A diferença do HD usando modo DMA e não usando é realmente considerável. Veja se você acha esse hdparm para sua distribuição.

    Quando ao medo de fsck remoto, vá em frente e faça, mas não use com a opção -y; mas sim -n: fsck /dev/hdLN -n
    Dessa forma você checa, mas não faz alterações, no entanto, ele irá te mostrar caso haja algum problema de alocação ou coisa do tipo.
    Prá achar setores defeituosos, você pode usar: badblocks -sv /dev/hdLN. Isso demora um tempo, e talvez seja melhor vocÊ rodar isso em background gerando o arquivo de log com os setores defeituosos (caso encontre): badblocks -o <nome_do_arquivo> /dev/hdLN (por exemplo, /dev/hda1 ou /dev/hda apenas).

    Ambos os testes que passei não são destrutivos, mesmo que encontre setores defeituosos / erros de disco. O máximo que pode acontecer, seria, ou o 'dmesg' se encher de mensagens de erro de leitura em disco, ou pior, em casos extremos do HD estar batendo cabeça MEESMO, de travar completamente o sistema ao ler determinado setor (se ele nao travou misteriosamente até hoje, nao deve ser o caso mesmo).

    Espero que ajude!..

  12. #12
    cag
    Visitante

    Padrão queda de energia, fsck.ext3

    beleza muito obrigado mesmo!

    não tem erro nenhum com o fsck, passou muito rápido

    Só falta verificar o badblock com a dica que você postou.

    Só uma observacao:
    1 mês depois quando precisei copiar um arquivo maior, percebi que demorou um pouco a mais.

    Então eu pensei, será que não corrigiu os erros da queda de energia ?
    Agora fiquei tranquilo, deve ser isso mesmo, não reconheceu o hd, está a 33.

    Outra coisa, pode ser alguma configuracao na bios, do hd trabalhar dessa forma ?
    Quero verificar as configuracoes da placa mãe, porque nem cheguei a mexer nisso.

    Nunca aconteceu algo desse tipo comigo.


    Valeu

  13. #13
    Avenger
    Visitante

    Padrão queda de energia, fsck.ext3

    Se for algo na BIOS, deve ser algo como aquele '32 bit' no local onde você configura os HDs (Standard CMOS, deixar aquilo em AUTO ou Habilitado), ou então no Advanced CMOS ou Peripheral, onde ele fala do Primary/Secondary Master/Slave PIO DMA-ou-algo-assim-MODE, que na dúvida fica em AUTO.

    Se sua BIOS tiver essas opções, confira elas de acordo com o que eu falei.

    Sobre meu post anterior.. hehe eu esqueci um pequeno detalhe que só realizei quando você me falou que o fsck passou muito rápido. Normalmente quando não tem porque passar fsck, ele simplesmente não passa, por padrão; então onde tinha o comando fsck -n use -fn no lugar de apenas -n. Isso vai garantir que o FSCK vá ser executado afundo, e que também não serão feitas modificações no sistema de arquivos (não vai corrigir os erros).

    Sobre o tal '33', normalmente o driver da controladora (onboard) de disco está compilado 'dentro do kernel', neste caso você precisa colocar lá no lilo, na seção correspondente ao kernel que você tá carregando, a linha append= com a opção idebus=66, deixando a linha do lilo assim:
    Código :
     append="idebus=66"
    ou, se tiver outra coisa no append (exemplo hdb=ide-scsi -- gravadora de CD)
    Código :
     append="hdb=ide-scsi idebus=66"

    Para ver se você realmente precisa desse idebus, você pode fazer um dmesg | grep 33 e checar se apareceu o texto: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx. Esse texto também aparece enquanto o linux, durante o boot, detecta as controladoras de discos e discos instalados no sistema. Se você carrega isso como módulo, seria por exemplo: modprobe sis5595 idebus=66 -- mas deveria ser durante o boot, então você teria que achar onde, nos rc.d da vida, o Linux faz o modprobe para sua controladora de disco.

    Espero que isso dê mais uma norteada aí!