☰

파일 시스템(ext4)은 TRIM 정보를 어떻게 "저장"합니까?

tag-icon • tag-icon ssd trim
파일 시스템(ext4)은 TRIM 정보를 어떻게 "저장"합니까?

매주 실행되는 TRIM 크론 작업을 활성화하는 것이 좋습니다. fstrim 명령이 호출되면 파일 시스템은 삭제된 데이터를 삭제하기 위해 드라이브에 TRIM 메시지를 보냅니다(제가 이 작업을 올바르게 수행하길 바랍니다).

여러 곳에서 설명했듯이 지금까지는 매우 좋습니다.

하지만 fstrim 명령 사이의 파일 시스템에서 이 TRIM 정보가 "저장"되는 방법/위치에 대한 정보를 찾을 수 없습니까?

SSD가 버려야 하는 모든 페이지/블록에 대한 정보를 얻지 못하도록 이 TRIM 정보를 "삭제"하는 방법이 있습니까?

아니면 fstrim 명령이 파일 시스템과 SSD를 비교하여 실제 삭제된 데이터를 확인합니까?

답변1

ext4가 실제로 그것을 어디에나 저장하는지 모르겠습니다. 다른 파일 시스템은 확실히 그렇지 않습니다.

ext4는 현재 세션에서 정리된 콘텐츠만 방지합니다(아직 마운트된 동안). 파일 시스템을 재부팅하거나 다시 마운트하면 빈 공간이 다시 정리됩니다.

따라서 이것은 전혀 저장되지 않는 메모리 구조일 수 있습니다. 나는 알아내기 위해 아주 좋은 소스 코드를 파헤쳐 보지 않았습니다.

약간의 테스트:

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

1G 파일 시스템이 주어지면 이를 마운트하고 정리해 보겠습니다.

# 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

그래서 먼저 모든 것을 정리합니다... 그것은 이미 수상한 일입니다. 결국 mkfs도 정리되었으므로(앗) 여전히 비어 있고 정리되어 있다는 것을 알아야 합니다. 그렇죠? 글쎄, 알고 있다면 상관하지 않습니다.

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

따라서 다시 설치한 후에는 사용 가능한 모든 공간을 다시 잘라냅니다.

파일을 생성하고 삭제할 때에도 정확하지 않습니다.

# 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

따라서 10M을 쓰면 117M이 다시 다듬어집니다. 그것은 아무런 의미가 없습니다.

SSD 자체만이 현재 정리된 내용과 정리되지 않은 내용을 알고 있으며, 이미 정리된 영역을 정리하라는 요청을 받으면 아무 작업도 수행해서는 안 됩니다. 따라서 손상이 발생하지 않으며 이 정보를 파일 시스템에 실제로 저장할 필요가 없습니다.

관련 정보