Re: TESTE DE INTEGRIDADE SSD

[Yuri Musachio]

Anderson, boa tarde!

Eu não entendi bem a sua dúvida, mas sobre a partição /boot eu consegui 
contornar isso.
Você não precisa adicionar a partição /boot ao RAID... Algo que você pode fazer 
é reconfigurar o grub para que, quando ele atualizar, o sistema identifica que 
existem duas partições /boot e irá atualizar as duas. Sendo assim, se em algum 
momento o disco 1 (principal) parar de funcionar, o segundo disco terá o /boot 
atualizado e irá conseguir iniciar corretamente.
PORÉM, existe um segundo pulo do gato que envolve o /boot e o fstab... É meio 
complicado descrever o problema, mas se trata do seguinte:
Após você rodar o reconfigure pros grubs/boot, você conseguirá adicionar a 
lista do fstab quais são os seus /boot (UUID). O que acontece é que, se o disco 
principal falhar, durante a inicialização do sistema, o sistema vai ler a 
primeira linha de /boot que será o UUID do /boot do disco principal que neste 
caso está fora, e por conta disso não conseguirá iniciar. OK, você até vai 
conseguir acessar a máquina e modificar o fstab para o segundo UUID de /boot 
passar a ser o principal, mas o intuito é isso ser invisível. Para este caso, 
você pode adicionar um mesmo LABEL para as partições /boot.
Logo, na identificação do fstab, ao invés de ter um UUID diferente para cada 
/boot, você irá identificar o label para montar no /boot. Neste caso, como as 
duas partições /boot dos dois discos possuem o mesmo LABEL, caso um /boot pare 
de funcionar (disco fora), ele irá iniciar pelo outro /boot do segundo disco.
Irei descrever abaixo os comandos:

Reconfigurar e identificar os /boot que serão atualizados em conjunto.
PS: É sempre indicado que os HDs sejam de mesma marca e capacidade, para que no 
momento da formatação do disco, o /boot secundário ficar identico ao principal.
# dpkg-reconfigure grub-efi-amd64

Adicionar LABEL aos /boot.
# dosfslabel /dev/boot1 "nome-label"
# dosfslabel /dev/boot2 "nome-label"

Modificar no fstab a linha que diz respeito ao /boot , trocando o UUID por 
LABEL.
LABEL=nome-label /boot 

Pra testar, já sabe... Desativa um HD, depois tenta iniciar pelo outro. Depois 
desativa o atual, e reinicia pelo que estava parado.
Interessante é que o RAID ainda irá funcionar lindamente, e nunca te dará dor 
de cabeça. :)
Espero ter ajudado!

Best,
On Mar 4 2024, at 1:10 pm, Anderson Rodrigues  
wrote:
> Por falar em Raid tem um problema que eu ainda não consegui contornar, 
> fazendo Raid em Software temos um problema para instalar o /Boot no Raid por 
> exemplo "md0/boot" o Grub não consegue ver esse diretório durante a 
> instalação uma forma de contornar isso é criar uma partição no disco somente 
> para o /boot, porém se esse disco for o que apresentar o problema perdemos o 
> acesso ao sistema, uma pergunta RAID em software é recomendado apenas para 
> máquinas desktops e não servidores, ou temos alguma forma de deixar o /boot 
> com grub em todos os discos de forma a não parar a máquina?
> Muito Obrigado a todos e um bom dia.
>
>
> Em sáb., 2 de mar. de 2024 às 16:01, Rafael de Almeida  (mailto:rafael.i...@gmail.com)> escreveu:
> > Galera,
> > Quem quiser saber mais sobre SSD no Linux
> > https://eriberto.pro.br/palestras/ssd-ref-biblio.pdf
> >
> >
> >
> > Em sáb., 2 de mar. de 2024 às 01:47, Leandro Cunha 
> > mailto:leandrocunha...@gmail.com)> escreveu:
> > > João, é você que realiza o processo pra se retirar da lista.
> > >
> > > https://lists.debian.org/debian-user-portuguese/
> > > Em qua., 28 de fev. de 2024, 14:37, João Pedro Nader Gervasoni 
> > > mailto:jnge...@hotmail.com)> escreveu:
> > > > Me retire desta lista
> > > >
> > > > Obter o Outlook para Android (https://aka.ms/AAb9ysg)
> > > > From: Jose Tavares  > > > (mailto:jaatavar...@gmail.com)>
> > > > Sent: Wednesday, February 28, 2024 2:02:14 AM
> > > > To: Yuri Musachio  > > > (mailto:yuri.musac...@gmail.com)>
> > > > Cc: Rafael de Almeida  > > > (mailto:rafael.i...@gmail.com)>; debian-user-portuguese 
> > > >  > > > (mailto:debian-user-portuguese@lists.debian.org)>
> > > > Subject: Re: TESTE DE INTEGRIDADE SSD
> > > >
> > > >
> > > > Me lembrei de algo extra..
> > > >
> > > > Se a máquina onde o SSD está ficar fazendo muito swap, e for colocado 
> > > > no SSD uma particao de swap muito pequena, alguns blocos do SSD serão 
> > > > super stressados com escrita e leitura, podendo danificar aquele espaco 
> > > > precocemente. A recomendacao é que o swap seja sempre 2x a quantidade 
> > > > de ram. Hoje em dia isto pode ser bastante de espaco desperdicado.
> > > > Lembrei disto pois já estourei SSD e nvme de laptops algumas vezes. lol 
> > > > ..
> > > > Deixa eu contar como aconteceu comigo o problema repetitivamente:
> > > > Se o cara ir atrás do MTBF dos modelos de SSD e ler quantos bytes eles 
> > > > aceitam de escrita antes de pifar, e então dividir os bytes pelo espaco 
> > > > de disco, se consegue saber quantas vezes um determinado bloco consegue 
> > > > aceitar escritas antes de estourar.
> > > >
> > > > 

Re: TESTE DE INTEGRIDADE SSD

[Paulo Ricardo Bruck]

Humm vou dar o meu pitaco pois faz muito tempo que não mexo com o msadm,
mas na época eu fazia um grub-install /dev/ sda; grub-install /dev/sdb

Em seg., 4 de mar. de 2024, 14:27, Anderson Rodrigues <
andersonrodrigues1...@gmail.com> escreveu:

> Por falar em Raid tem um problema que eu ainda não consegui contornar,
> fazendo Raid em Software temos um problema para instalar o /Boot no Raid
> por exemplo "md0/boot" o Grub não consegue ver esse diretório durante a
> instalação uma forma de contornar isso é criar uma partição no disco
> somente para o /boot, porém se esse disco for o que apresentar o problema
> perdemos o acesso ao sistema, uma pergunta RAID em software é recomendado
> apenas para máquinas desktops e não servidores, ou temos alguma forma de
> deixar o /boot com grub em todos os discos de forma a não parar a máquina?
> Muito Obrigado a todos e um bom dia.
>
> Em sáb., 2 de mar. de 2024 às 16:01, Rafael de Almeida <
> rafael.i...@gmail.com> escreveu:
>
>> Galera,
>> Quem quiser saber mais sobre SSD no Linux
>> https://eriberto.pro.br/palestras/ssd-ref-biblio.pdf
>>
>> Em sáb., 2 de mar. de 2024 às 01:47, Leandro Cunha <
>> leandrocunha...@gmail.com> escreveu:
>>
>>> João, é você que realiza o processo pra se retirar da lista.
>>>
>>> https://lists.debian.org/debian-user-portuguese/
>>>
>>> Em qua., 28 de fev. de 2024, 14:37, João Pedro Nader Gervasoni <
>>> jnge...@hotmail.com> escreveu:
>>>
 Me retire desta lista

 Obter o Outlook para Android 
 --
 *From:* Jose Tavares 
 *Sent:* Wednesday, February 28, 2024 2:02:14 AM
 *To:* Yuri Musachio 
 *Cc:* Rafael de Almeida ;
 debian-user-portuguese 
 *Subject:* Re: TESTE DE INTEGRIDADE SSD

 Me lembrei de algo extra..

 Se a máquina onde o SSD está ficar fazendo muito swap, e for colocado
 no SSD uma particao de swap muito pequena, alguns blocos do SSD serão super
 stressados com escrita e leitura, podendo danificar aquele espaco
 precocemente. A recomendacao é que o swap seja sempre 2x a quantidade de
 ram. Hoje em dia isto pode ser bastante de espaco desperdicado.

 Lembrei disto pois já estourei SSD e nvme de laptops algumas vezes. lol
 ..
 Deixa eu contar como aconteceu comigo o problema repetitivamente:
 Se o cara ir atrás do MTBF dos modelos de SSD e ler quantos bytes eles
 aceitam de escrita antes de pifar, e então dividir os bytes pelo espaco de
 disco, se consegue saber quantas vezes um determinado bloco consegue
 aceitar escritas antes de estourar.

 Depois o cara cria o swap 2x o tamanho da ram e passa a hibernar a
 máquina no trajeto pro office e no trajeto pra casa, o que seria uma boa
 prática. Dois hibernates por dia, duas escritas da ram no SSD, no mesmo
 espaco do swap, vezes uns 2 anos fazendo isto e plim, o SSD comeca a ficar
 lerdo quando se vai hibernar (realocando) e uma hora dá zebra. É só fazer
 os calculos, mas pelos 2 anos o problema acontece.

 Jose Tavares


 On Wed, Feb 28, 2024 at 1:44 AM Jose Tavares 
 wrote:

 Alguns fabricantes de SSD tem produtos muito ruins.

 Instala o pacote smartmontools, e usa o smartctl fazendo teste short e
 long .. Quando disparares o teste, verifica quanto tempo irá levar e depois
 de concluir o tempo, com o parâmetro -a consegues ver o resultado.

 O smart roda em background, então não afeta a perf da máquina. Lê com
 atenção os resultados.

 Uma tool simples que recomendo é o f3.
 https://fight-flash-fraud.readthedocs.io/en/latest/introduction.html
 Foi escrita por um brasileiro.

 Basicamente o que ela faz é escrever padrões em toda a memória flash e
 depois lê e compara os resultados. Com isto, dá para ver se há diferenças
 na escrita e depois leitura, o que indicaria erro no armazenamento. Serve
 para qualquer tipo de armazenamento.

 Durante as operações, acompanhe os logs da máquina para ver se acontece
 resets nas controladoras de disco.

 Sobre raid1, é uma opção, mas utilize preferivelmente 2 marcas de SSD
 diferentes, para contornar problemas de fabricantes e de modelos
 específicos. Outra opção é usar um SSD e um HDD, e então configurar
 write-mostly para que todas as leituras se dêem somente do SSD e as
 escritas em ambos para não ter perda de performance significativa.

 Uma coisa que costumo sempre fazer antes de usar qualquer disco é rodar
 um dd if= of=/dev/null
 Desta forma fazendo uma leitura completa do disco antes de começar o
 seu uso. Nisto já se percebe se houver erros. É possível também fazer
 testes de escrita e leitura usando o fsck.ext4 com -cc caso o disco tenha
 sido configurado com ext4.. O comando shred também pode te ajudar fazendo
 passes no disco e vendo resultados.

 Mas de todas opções, o f3 me parece 

Re: TESTE DE INTEGRIDADE SSD

[Anderson Rodrigues]

Por falar em Raid tem um problema que eu ainda não consegui contornar,
fazendo Raid em Software temos um problema para instalar o /Boot no Raid
por exemplo "md0/boot" o Grub não consegue ver esse diretório durante a
instalação uma forma de contornar isso é criar uma partição no disco
somente para o /boot, porém se esse disco for o que apresentar o problema
perdemos o acesso ao sistema, uma pergunta RAID em software é recomendado
apenas para máquinas desktops e não servidores, ou temos alguma forma de
deixar o /boot com grub em todos os discos de forma a não parar a máquina?
Muito Obrigado a todos e um bom dia.

Em sáb., 2 de mar. de 2024 às 16:01, Rafael de Almeida <
rafael.i...@gmail.com> escreveu:

> Galera,
> Quem quiser saber mais sobre SSD no Linux
> https://eriberto.pro.br/palestras/ssd-ref-biblio.pdf
>
> Em sáb., 2 de mar. de 2024 às 01:47, Leandro Cunha <
> leandrocunha...@gmail.com> escreveu:
>
>> João, é você que realiza o processo pra se retirar da lista.
>>
>> https://lists.debian.org/debian-user-portuguese/
>>
>> Em qua., 28 de fev. de 2024, 14:37, João Pedro Nader Gervasoni <
>> jnge...@hotmail.com> escreveu:
>>
>>> Me retire desta lista
>>>
>>> Obter o Outlook para Android 
>>> --
>>> *From:* Jose Tavares 
>>> *Sent:* Wednesday, February 28, 2024 2:02:14 AM
>>> *To:* Yuri Musachio 
>>> *Cc:* Rafael de Almeida ; debian-user-portuguese
>>> 
>>> *Subject:* Re: TESTE DE INTEGRIDADE SSD
>>>
>>> Me lembrei de algo extra..
>>>
>>> Se a máquina onde o SSD está ficar fazendo muito swap, e for colocado no
>>> SSD uma particao de swap muito pequena, alguns blocos do SSD serão super
>>> stressados com escrita e leitura, podendo danificar aquele espaco
>>> precocemente. A recomendacao é que o swap seja sempre 2x a quantidade de
>>> ram. Hoje em dia isto pode ser bastante de espaco desperdicado.
>>>
>>> Lembrei disto pois já estourei SSD e nvme de laptops algumas vezes. lol
>>> ..
>>> Deixa eu contar como aconteceu comigo o problema repetitivamente:
>>> Se o cara ir atrás do MTBF dos modelos de SSD e ler quantos bytes eles
>>> aceitam de escrita antes de pifar, e então dividir os bytes pelo espaco de
>>> disco, se consegue saber quantas vezes um determinado bloco consegue
>>> aceitar escritas antes de estourar.
>>>
>>> Depois o cara cria o swap 2x o tamanho da ram e passa a hibernar a
>>> máquina no trajeto pro office e no trajeto pra casa, o que seria uma boa
>>> prática. Dois hibernates por dia, duas escritas da ram no SSD, no mesmo
>>> espaco do swap, vezes uns 2 anos fazendo isto e plim, o SSD comeca a ficar
>>> lerdo quando se vai hibernar (realocando) e uma hora dá zebra. É só fazer
>>> os calculos, mas pelos 2 anos o problema acontece.
>>>
>>> Jose Tavares
>>>
>>>
>>> On Wed, Feb 28, 2024 at 1:44 AM Jose Tavares 
>>> wrote:
>>>
>>> Alguns fabricantes de SSD tem produtos muito ruins.
>>>
>>> Instala o pacote smartmontools, e usa o smartctl fazendo teste short e
>>> long .. Quando disparares o teste, verifica quanto tempo irá levar e depois
>>> de concluir o tempo, com o parâmetro -a consegues ver o resultado.
>>>
>>> O smart roda em background, então não afeta a perf da máquina. Lê com
>>> atenção os resultados.
>>>
>>> Uma tool simples que recomendo é o f3.
>>> https://fight-flash-fraud.readthedocs.io/en/latest/introduction.html
>>> Foi escrita por um brasileiro.
>>>
>>> Basicamente o que ela faz é escrever padrões em toda a memória flash e
>>> depois lê e compara os resultados. Com isto, dá para ver se há diferenças
>>> na escrita e depois leitura, o que indicaria erro no armazenamento. Serve
>>> para qualquer tipo de armazenamento.
>>>
>>> Durante as operações, acompanhe os logs da máquina para ver se acontece
>>> resets nas controladoras de disco.
>>>
>>> Sobre raid1, é uma opção, mas utilize preferivelmente 2 marcas de SSD
>>> diferentes, para contornar problemas de fabricantes e de modelos
>>> específicos. Outra opção é usar um SSD e um HDD, e então configurar
>>> write-mostly para que todas as leituras se dêem somente do SSD e as
>>> escritas em ambos para não ter perda de performance significativa.
>>>
>>> Uma coisa que costumo sempre fazer antes de usar qualquer disco é rodar
>>> um dd if= of=/dev/null
>>> Desta forma fazendo uma leitura completa do disco antes de começar o seu
>>> uso. Nisto já se percebe se houver erros. É possível também fazer testes de
>>> escrita e leitura usando o fsck.ext4 com -cc caso o disco tenha sido
>>> configurado com ext4.. O comando shred também pode te ajudar fazendo passes
>>> no disco e vendo resultados.
>>>
>>> Mas de todas opções, o f3 me parece o mais fácil e direto para os teus
>>> testes, e irá acusar problemas se houverem.
>>>
>>> Ah, e execute todos os testes antes de colocar o disco em produção.
>>>
>>> Espero ter ajudado.
>>> Jose Tavares
>>>
>>>
>>> On Wed, Feb 28, 2024 at 12:00 AM Yuri Musachio 
>>> wrote:
>>>
>>> MUITO FÁCIL fazer o RAID1 (no Debian)… chega a ser ridículo! PORÉM,
>>> existem