아주 예전에는, 하드 디스크는 커다란 종이처럼 원하는 주소 아무데나 write 하며 사용했다.

 

이런 방식이 사용이 불편하니, 저장소를 관리하는 파일시스템이 탄생했다. 파일시스템은 파일별로 고유 inode를 만들어 실제 파일이 저장되는 저장소와 연결한다. 모든 Inode는 inode table에 저장된다.

 

파일을 추가할 때, 파일시스템은 저장소에서 사용되지 않는 영역을 확인한다. 그곳에 파일 내용을 작성하고, 파일을 가르키는 inode 항목을 추가한다. 그 파일을 읽을 때는 Inode를 통해 파일 내용을 읽어들인다.

 

파일을 삭제할때는 파일 내용을 삭제할 수 도 있지만, inode를 table에서 제거하고 블록을 할당 해제하면 간단하다. 이렇게 하면 파일 삭제는 즉시 수행되고, 새 파일에 블록이 할당되면 덮어쓰게 된다.

 

이런 과정에서 filesystem과 inode 없이 저장소만 본다면, 어떤 데이터가 사용중인지, 삭제되어 덮어쓰기가 될 내용인지 구별할 수 없다. 그냥 비트 덩어리일 뿐이다.

 

하드 디스크는 각 주소를 실제 물리적인 디스크 주소에 맵핑하므로 이러한 방식이 괜찮지만, ssd는 플래시 메모리 기반이므로 반복적인 쓰기에 취약하므로 좋지 않다. 같은 주소에 반복적인 쓰기가 계속 발생하면 해당 cell만 노후화가 급격히 진행된다.

 

그래서 OS에는 똑같이 보이는 저장소를 제공해 호환성을 가진 인터페이스를 제공하고, 펌웨어에서 블록을 재할당하는 방법이 생겨났다. 같은 주소에 반복적인 쓰기가 일어났을 때, ssd-controller가 새로운 블록에 쓰도록 변경해버리고 나중에 찾을 수 있도록 구성을 기억해놓는다. 이것이 wear-leveling이라 한다. 이상적으로는 계속 같은 논리적 주소에 write를 하더라도 모든 cell이 동등하게 노후화가 진행된다.

 

하지만 문제점이 있는데, 블록을 재할당 하려면 어떤 블록이 할당되지 않았는지 알아야 한다. 하지만 파일시스템의 삭제는 실제 데이터를 삭제하지 않기 때문에 어떤 블록이 지워진 블록인지 알 수 없다.

 

그래서 파일시스템에게 스토리지에 어떤 블록이 삭제되었는지 알려줘야 하는데, 이것이 trim이다.

 

thin-provisioning을 하는 지능형 스토리지 역시 실제 raw data를 삭제하지 않고 inode만 삭제하는 경우, raw data가 스토리지에 계속 남아있게 된다. 그래서 trim을 수행해 스토리지에 실제 삭제된 블록을 알려 용량을 회수해야 한다.

 

최신 파일시스템은 파일이 삭제되면 trim이 자동으로 수행되는데, 구식 파일시스템은 주기적으로 모든 파일시스템에 대해 fstrim을 수행해줘야 한다.

728x90
반응형

'OS & Container > Storage' 카테고리의 다른 글

DAS, SAN  (0) 2022.03.31
스토리지 프로비저닝  (0) 2022.03.22
스토리지 시스템 컴포넌트  (0) 2022.03.21
RAID 정리, 핫 스페어  (0) 2022.03.18
RAID와 디스크 성능  (0) 2022.03.16

+ Recent posts