fstrim não se lembra de blocos trmmed após a reinicialização

0

Eu uso a criptografia de disco completo do LUKS + LVM (/ boot incluído).

No entanto, após cada reinicialização, o sistema cortará tudo por espaço livre, não lembrando quais blocos foram cortados.

Eu tenho medo que isso vai desgastar meu ssd.

Aug 07 15:49:18 /: 338.4 GiB (363312041984 bytes) trimmed
[REBOOT]
Aug 07 15:49:45 /: 225.5 MiB (236392448 bytes) trimmed
[NO REBOOT]
Aug 07 16:00:01 /: 1.4 GiB (1476653056 bytes) trimmed
[REBOOT]
Aug 09 08:08:43 /: 338.3 GiB (363260616704 bytes) trimmed
[NO REBOOT]
Aug 09 10:00:02 /: 1.6 GiB (1708560384 bytes) trimmed
[NO REBOOT]
Aug 09 16:00:02 /: 1.2 GiB (1317408768 bytes) trimmed
[NO REBOOT]
Aug 10 09:10:24 /: 4.9 GiB (5261406208 bytes) trimmed
[REBOOT]
Aug 10 15:02:24 /: 338.3 GiB (363209334784 bytes) trimmed

Este é o comportamento correto? Espero que, após a reinicialização, continue aparando apenas alguns GiB, e não todo o espaço livre.

    
por anonimou 10.08.2018 / 20:11

1 resposta

1

Tanto quanto eu entendo SSDs, fstrim e as coisas relevantes, parece assim:

TL; DR Em SSDs normais, executar fstrim novamente nas mesmas áreas geralmente não deve afetar nada.

fstim repassa todo o sistema de arquivos, verifica quais blocos não estão sendo usados pelo fs e informa a unidade.

Assim, o SSD obtém um comando TRIM "o bloco 123 não está sendo usado pelo SO, você pode fazer o que quiser com ele." A maioria dos SSDs marca o bloco como não utilizado e efetivamente zera o conteúdo. Assim, no próximo comando TRIM para o mesmo bloco do SSD geralmente vai fazer isso: ". Ei, já é marcado como não utilizado não estou fazendo qualquer coisa e dizer ao usuário, ele foi bem sucedido"

Você pode usar smartctl --xall /dev/sdX antes e depois de uma fstrim para verificar os valores de nivelamento de desgaste (a maioria dos SSDs têm alguns atributos para nivelamento de desgaste). Eles não devem mudar muito. Apenas muito pouco para os poucos blocos que seus daemons / etc mudaram.

    
por 10.08.2018 / 21:52