☰

TRIM에는 "드롭" 설치가 필요합니까?

tag-icon • tag-icon mount data-recovery ssd trim
TRIM에는 "드롭" 설치가 필요합니까?

해당 옵션을 사용하여 SSD를 설치할지 궁금합니다 discard.man mount) 실제로 ATA TRIM을 SSD 컨트롤러로 보내야 합니다.

discard증거는 다소 정황 적입니다.샌디스크 SSD 플러스, 삭제된 파일은 즉시 TestDisk를 실행하여 복구할 수 없습니다. 파일 경로는 그대로인데 파일 내용이 사라졌습니다. 이로부터 TRIM이 SSD에서 실행되고 있어 파일 내용을 복구할 수 없게 만드는 것으로 의심됩니다.

살펴보니 systemctl list-timers런닝 유닛은 없는 것 같습니다 fstrim.

파티션이 마운트되지 않았음에도 파일이 삭제된 후 커널이 TRIM을 보냅니까 discard? 아니면 TestDisk가 SSD에서 파일을 안정적으로 복구할 수 없는 또 다른 이유입니까?

저는 아치 리눅스 5.12.3을 사용하고 있습니다.

findmnt파티션과 마운트 옵션에 대해 알려주십시오.

TARGET                       SOURCE     FSTYPE OPTIONS
/                            /dev/sda3  ext4   rw,relatime
└─/sda1                      /dev/sda1  ext4   rw,relatime,lazytime,discard

답변1

파일 시스템이 마운트된 경우 discard파일을 삭제하면 자동으로 TRIM 명령이 실행됩니다. 이는 종종 성능에 부정적인 영향을 미치므로 일반적으로 해당 마운트 옵션을 사용하지 않고 정기적으로 실행하는 것이 좋습니다 fstrim. 이는 모든 블록 장치 계층이 이를 지원하는 한 작동합니다(예: 암호화에 LUKS를 사용하는 경우 을 사용해야 합니다 cryptsetup --allow-discards. 이 마운트 옵션을 사용하지 않으면 파일 링크를 해제할 때 파일 시스템 드라이버가 자동으로 TRIM 명령을 보내지 않습니다.

를 사용하여 설치해 볼 수도 있습니다 nodiscard. 이는 기본값이고 일반적으로 필요하지 않지만 파일 시스템에 를 통해 지속적인 TRIM 지원이 추가되었을 수 있습니다 tune2fs -o discard /dev/sda1.tune2fs -o ^discard /dev/sda1

debugfs이 유틸리티를 사용하면 파일을 삭제하기 전에 먼저 파일의 실제 블록을 나열한 다음 삭제 후 블록에 직접 액세스하여 해당 블록이 0이 되었는지 또는 방해받지 않았지만 할당되지 않은 데이터를 반환하는지 확인하여 문제가 무엇인지 알아낼 수 있습니다.

debugfs다음은 삭제된 파일의 내용을 블록 번호를 사용하여 읽을 수 있는지 테스트하는 쉘 스크립트입니다 .

#!/bin/sh

file=test_file
echo "Current date: $(date)" > "$file"; sync
# Get the device of our test file, for example "/dev/sda1"
device=$(df -P "$file" | awk 'END{print $1}')
# The block of the file's contents, stat gets the inode number
block=$(sudo debugfs -R "blocks <$(stat -c %i "$file")>" "$device")
rm $file; sync
# Read the contents of the deleted file, -D bypasses the buffer cache
sudo debugfs -D -R "block_dump $block" "$device"

관련 정보