이곳에서 라즈베리파이 등의 제품에서 USB SSD를 메인스토리지로 사용하는 방법등의 팁을 얻어
ODROID XU4 를 Cloudshell2 에 장착하여 소규모 개발 및 네트워크 스토리지로 오랜기간 잘 사용하고있었습니다만...
최근 도커 이미지 설치중 SSD가 갑자기 IO 오류를 뿜기 시작했습니다.
장착시 S.M.A.R.T 상의 미디어 소모 지표는 90%남짓 이였지만 (구형 120GB 인텔 MLC SSD) 오류를 뿜는 현재 소모지표는
53%로 아직까지는 꽤나 사용가능(?)할 정도로 웨어율이 아직은 심각한 정도는 아님에도 불구하고
IO 오류를 뿜는 이유를 생각해보니 TRIM의 부재가 아닌가 하는 의심에 기반하여
TRIM서비스가 제대로 동작하고 있는지 확인을 먼저 하였습니다.
제대로 동작은 하고 있지만 실제로 동작했는지 알수 없어 강제 트림을 실행해 보았습니다.
root@pstudio:# fstrim / -v
fstrim / : the discard operation is not supported
제대로 실행 하려면 /etc/fstab 에 discard 옵션이 추가 되어있어야 동작할 수 있습니다. 라는 내용의 글을 보고
/etc/fstab에 discard 옵션을 주어 fstrim을 실행해도 같은 결과였습니다
라즈베리파이 포럼의 설명상으로는 USB SATA 어뎁터가 UNMAP/TRIM을 지원하는 제품에서
udev 규칙을 추가하여 fstrim 을 활성화 할수있다고 설명하고있습니다.
https://www.raspberrypi.org/forums/viewtopic.php?t=253915
ACTION=="add|change", ATTRS{idVendor}=="<VID>", ATTRS{idProduct}=="<PID>", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap" |
여기서 VID와 PID는 lsusb 결과에 있는 ID 뒤의 9자리중 :를 제외한 숫자문자들입니다. 콜론을 기준으로 앞이 VID , 뒤가 PID 입니다.
제 메인 SSD 는 ASMedia 사의 ASM1153E에 물려있고 CloudShell2의 SATA는 JMicron 사의 JM551(실제로는 JM561)입니다.
VID는 174c PID는 55aa네요.
/etc/udev/rules.d/ 폴더에 10-trim.rules 라는 파일을 만들어
위의 박스 내용에 <VID>와 <PID>를 대체 하여 저장하고 시스템을 재시작합니다.
재시작 후 fstrim 결과입니다.
어뎁터가 unmap과 trim 을 지원하는지 여부는 하단 링크에서 확인 했습니다.
https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi
알리표 저가형 USB to SATA 제품을 사용하고 있음에도 TRIM 이 잘동작 하는 것을 보면 대부분 문제없이 잘 적용 될거라 생각됩니다.
TRIM이후, 저장 할때 IO 에러 문제는 잘 해결되었습니다.
그런 내용의 discard 옵션이였군요. 감사합니다 또 하나 알아가네요.
성능상 discard는 빼고 fstrim.timer를 사용하는게 났겠군요.
경험이라면 SSD 초창기 SLC와 MLC 공존하던 시절 INTEL RAID 사용때 TRIM이 안되어 고생했던 기억이 있습니다. (비슷한 IO 쓰기 문제)
지금은 INTEL RAPID STORAGE의 드라이버가 설치되면 알아서 잘 처리 해주는걸로 알고있습니다.
모니터가 없는 NAS 환경이다 보니 원격에선 한계가 있어 윈도우 환경에서 여러가지 확인을 해보았지만 특별한 문제는 발견하지 못하였지만 윈도우 환경에 다녀와서는 오류 문제가 해결되어 있었습니다.
그래서 생각 했던것이 TRIM이 안되고 있는게 아닌가 라는 생각을 하게됬네요.
조금 늦게 발견했으면 SSD에 시스템 로그를 쓰다가 IO오류가 발생해서 번거로운 작업을 거쳐 복구할 상황이 발생했을테니 다행이라 생각합니다.