fstrim apara mais da metade do tamanho da partição, mesmo que a partição seja montada com o descarte

Question

Quando instalei o meu SSD, montei com discard e não fiquei com ele. No entanto, hoje eu estava lendo sobre os prós e contras de usar fstrim e decidi executar o programa para ter uma idéia de quanto tempo ele realmente demoraria (ainda com minhas partições montadas com discard ). O comando levou vários minutos nas minhas partições raiz e home. Para minha partição inicial, usei -v e obtive isso:

$ sudo fstrim -v /home
/home: 137494052864 bytes were trimmed

Isso é mais do que a quantidade de espaço livre na partição!

$ df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       206G   78G  118G  40% /home

Execuções subseqüentes terminam em menos de um segundo, por exemplo:

$ sudo fstrim -v /home
/home: 0 bytes were trimmed

Certamente, se eu sempre tive a partição montada com discard , fstrim não deve aparar uma grande quantidade de dados como esse? A opção discard está definitivamente ativada, aqui estão as% relevantesfstab lines:

UUID=xxxxxxxx...    /          ext4   noatime,discard,errors=remount-ro  0      1
UUID=xxxxxxxx...    /home      ext4   noatime,discard,errors=remount-ro  0      2

E mount linhas de saída:

/dev/disk/by-uuid/xxxxxxxx... on / type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)
/dev/sda2 on /home type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)

O SSD é um THOSNS256GMCP da TOSHIBA. Por que isso acontece?

    

Answer 1

Duas coisas aqui:

1. fstrim apara todos os dados não alocados no sistema de arquivos (bem, não todos os dados, apenas os blocos de dados que não estão alocados, eu não acho que as partes não usadas da tabela de inode ou as partes de blocos não completamente usados são aparados), independentemente de discard estar em uso ou não. fstrim não pode saber quais desses blocos não alocados foram "aparados" ou não no passado, mas (na verdade, o kernel, todo o fstrim trabalho é feito no FITRIM ioctl ), no entanto, acompanha dos quais grupo de blocos foram aparados e não serão reduzidos novamente se não houver nenhuma desalocação nesse grupo de blocos desde então, a menos que você esteja solicitando um FITRIM com um comprimento de extensão mínimo menor (de verificando o código ext4, pode ser diferente para outros sistemas de arquivos) o que explica porque você obtém 0 na próxima execução.

   Observe que não é prejudicial aparar um bloco que já tenha sido aparado. Isso é apenas dizer ao SSD novamente que ele pode fazer o que quiser com ele (como apagá-lo para que ele esteja pronto para ser usado novamente para outra coisa).

2. Em df output, o valor "disponível" não leva em conta o espaço "reservado" para root , você notará que 206 - 76 é 130G, não 118G. 12G (cerca de 5%) são reservados. Veja tunefs -m para alterar quanto está reservado.