Trim no SSD realmente ativado?

[Keviny]

Boa Noite galera do CDH, eu estou em um estado confuso com o meu SSD e queria saber se o TRIM está realmente ativado, pois toda vez que reseto o meu xubuntu e faço um "sudo trim -v /" no terminal vejo algo assim:

 

 

Eu queria saber se isso é normal 

adicionado 2 minutos depois

Esqueci de mencionar o meu fstab está assim, se isso influenciar:

 

Estou usando xubuntu 16.04.5 (kernel 4.4.0-141-lowlatency)

[Marcos FRM]

É assim mesmo. Essa discrepância entre as invocações do fstrim é porque o EXT4 memoriza quais blocos foram "trimados" até a próxima inicialização. Se você criar alguns arquivos, depois excluí-los e rodar o programa novamente, deverá mostrar quantidade de bytes maior que zero. Se não me engano, o XFS se comporta de forma diferente: sempre "trima" tudo.

 

Note, contudo, que com a opção de montagem "discard" você não precisa rodar o fstrim regularmente, pois o sistema de arquivos já faz isso automaticamente. O problema, porém, é que, com a opção de montagem, em dispositivos que não suportem NCQ TRIM, há perda de desempenho. Escrevi algo sobre isso aqui. Talvez seja melhor remover "discard" do fstab e deixar o script /etc/cron.weekly/fstrim do Ubuntu tomar conta disso para você.

[Keviny]

5 horas atrás, Marcos FRM disse:

É assim mesmo. Essa discrepância entre as invocações do fstrim é porque o EXT4 memoriza quais blocos foram "trimados" até a próxima inicialização. Se você criar alguns arquivos, depois excluí-los e rodar o programa novamente, deverá mostrar quantidade de bytes maior que zero. Se não me engano, o XFS se comporta de forma diferente: sempre "trima" tudo.

 

Note, contudo, que com a opção de montagem "discard" você não precisa rodar o fstrim regularmente, pois o sistema de arquivos já faz isso automaticamente. O problema, porém, é que, com a opção de montagem, em dispositivos que não suportem NCQ TRIM, há perda de desempenho. Escrevi algo sobre isso aqui. Talvez seja melhor remover "discard" do fstab e deixar o script /etc/cron.weekly/fstrim do Ubuntu tomar conta disso para você.

 

Valeu, eu tive uma pequena perda de desempenho em escrita ultimamente, mas não pensava que a causa podia ser o discard no fstab, li o seu post, mas o meu problema é que o resultado é sempre o mesmo após reiniciar o computador (com exceção do primeiro boot do dia ele faz o trim e quando executo o comando "trim -v /" ele exibe

/: 0 B (0 bytes) trimmed)

[Keviny]

@Marcos FRM  Fiz um testes aqui e retirando o discard do fstab o trim não inicia nem no primeiro boot do dia, mas para sanar o problema eu criei um script no systemd para "trimar" o ssd, está funcionando (pelo menos na segunda partição trimou tudo), mas já na raiz trimou, mas não tudo deve ser por causa da partição /tmp (e dá partição /var eu acho), mas causaria algum problema o sistema ficar sempre rodando o trim no boot?

[Marcos FRM]

Ubuntu e derivados têm /etc/cron.weekly/fstrim que faz isso para você (outras distros usam a solução oficial da suíte util-linux: fstrim.{service,timer}). Ah, e o firmware pode simplesmente ignorar o comando se assim desejar. Há modelos que zeram os setores trimados e outros que não, para ver como o firmware pode fazer o que bem entender.

 

Desencana. Não coloque SSD num pedestal. Eu fiz isso lá em 2011 quando comprei meu primeiro SSD. Hoje, não dou a mínima para eles. Para mim são como discos rígidos. Apenas certifico que uma vez por semana o fstrim rodará, que é o padrão das distros de qualquer maneira, seja pelo arquivo .timer ou pelo cron...

 

Apenas mereceria alguma configuração manual caso eu pegasse um modelo com NCQ TRIM. Daí valeria a pena tentar substituir TRIM periódico pela opção de montagem discard -- e pendurar uma ferradura na parede por garantia, pois os primeiros firmwares que implementavam o recurso eram bugados demais e corrompiam dados quando o sistema operacional enviava o comando.

[Keviny]

@Marcos FRM  Eu acho que você tem razão, talvez eu esteja exagerando querendo forçar o trim toda vez que eu bootar o sistema, Eu acho que só vou deixar o trim ser executado no cron mesmo, valeu.