Início / unix / Perguntas / 499577
Accepted
MrCalvin
Asked: 2019-02-09 15:10:46 +0800 CST

Como o sistema de arquivos (ext4) "armazena" as informações do TRIM?

  • 772

Recomenda-se habilitar um TRIM cron job que é executado uma vez por semana. Quando o comando fstrim é chamado, o sistema de arquivos enviará informações de TRIM para a unidade para descartar os dados excluídos (espero ter acertado)

Até agora tudo bem, isso é descrito em muitos lugares.

Mas não consigo encontrar nenhuma informação sobre como/onde essas informações do TRIM são "armazenadas" no sistema de arquivos entre os comandos fstrim?

E essas informações de TRIM podem ser "limpas" de alguma forma para que o SSD não obtenha as informações de todas as páginas/blocos que devem ser descartados?

Ou o comando fstrim comparará o sistema de arquivos e o SSD em relação a quais dados são realmente excluídos?

ssd trim

1 respostas

  1. Best Answer

    Não sei se o ext4 realmente o armazena em qualquer lugar. Outros sistemas de arquivos certamente não.

    ext4 evita o que já cortou apenas na sessão atual - enquanto ainda está montado. Depois de reinicializar ou remontar o sistema de arquivos, ele apenas TRIMs esvazia o espaço novamente.

    Portanto, isso pode ser uma estrutura na memória que não é armazenada. Eu não mergulhei no código-fonte muito fino para descobrir.

    Um pequeno teste:

    # truncate -s 1G /dev/shm/foobar.img
# losetup --find --show /dev/shm/foobar.img
/dev/loop9
# mkfs.ext4 /dev/loop9
# mkdir /mnt/loop

    Dado um sistema de arquivos 1G, vamos montá-lo e apará-lo:

    # mount /dev/loop9 /mnt/loop/
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
# fstrim -v /mnt/loop
/mnt/loop: 0 B (0 bytes) trimmed

    Então primeiro apara tudo... só isso já é suspeito, afinal: mkfs já aparava também (ai), então deve saber que ainda está vazio e aparado, certo? Bem, se ele sabe, não se importa:

    # umount /mnt/loop
# mount /dev/loop9 /mnt/loop
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed

    Então, após a remontagem, ele apenas corta todo o espaço livre novamente.

    Ao criar e excluir arquivos, também não há precisão exata:

    # dd bs=1M count=10 if=/dev/zero of=/mnt/loop/zerofile
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0124641 s, 841 MB/s
# sync
# rm /mnt/loop/zerofile
# fstrim -v /mnt/loop
/mnt/loop: 117.5 MiB (123203584 bytes) trimmed

    Assim, escrever 10M causa um novo corte de 117M. Simplesmente não significa nada.

    Somente o próprio SSD realmente sabe o que está atualmente aparado e o que não, e quando solicitado a aparar uma área já cortada, ele simplesmente não deve fazer nada. Portanto, não há problema e não há necessidade de realmente armazenar essas informações no sistema de arquivos.

    • 7

relate perguntas