SMR은 순차적으로만 쓰기 위해 무작위로 쓰기를 원하는 LBA용 매핑 시스템을 사용합니다. SSD의 FTL(Flash Translation Layer)과 유사하게 SMR HDD는 SMR(또는 Shingle) Translation Layer(STL)라고도 하는 유사한 개념을 사용합니다. 그러나 SMR을 사용하면 호스트가 기본 SMR 기술을 인식하게 함으로써 훨씬 더 많은 것을 얻을 수 있습니다. 업계는 ZBC(Zoned Block Commands)가 SAS의 표준이 되고 ZAC(Zoned ATA Commands)가 SATA의 표준이 되는 SMR의 표준화 프로세스의 마지막 단계에 있습니다. 이러한 표준은 LBA 공간이 독립적인 영역으로 분할되는 영역 블록 장치를 정의합니다. 각 영역 내에서 쓰기는 순차적이어야 합니다. 데이터를 덮어쓰려면 SSD의 지우기 블록과 마찬가지로 영역을 먼저 재설정해야 합니다. 비순차적 쓰기가 영역으로 전송될 때 발생하는 상황은 SMR 구현 유형에 따라 다릅니다.
SMR은 순차적으로만 쓰기 위해 무작위로 쓰기를 원하는 LBA용 매핑 시스템을 사용합니다. SSD의 FTL(Flash Translation Layer)과 유사하게 SMR HDD는 SMR(또는 Shingle) Translation Layer(STL)라고도 하는 유사한 개념을 사용합니다. 그러나 SMR을 사용하면 호스트가 기본 SMR 기술을 인식하게 함으로써 훨씬 더 많은 것을 얻을 수 있습니다. 업계는 ZBC(Zoned Block Commands)가 SAS의 표준이 되고 ZAC(Zoned ATA Commands)가 SATA의 표준이 되는 SMR의 표준화 프로세스의 마지막 단계에 있습니다. 이러한 표준은 LBA 공간이 독립적인 영역으로 분할되는 영역 블록 장치를 정의합니다. 각 영역 내에서 쓰기는 순차적이어야 합니다. 데이터를 덮어쓰려면 SSD의 지우기 블록과 마찬가지로 영역을 먼저 재설정해야 합니다. 비순차적 쓰기가 영역으로 전송될 때 발생하는 상황은 SMR 구현 유형에 따라 다릅니다.
SMR 드라이브는 세 가지 범주로 분류됩니다. 보다 정확하게는 세 가지 유형의 관리 드라이브 공급업체가 사용할 수 있습니다. 각각 고유한 장점과 단점이 있습니다.
드라이브 관리
첫 번째 유형은 투명이라고도 하는 드라이브 관리 유형입니다. 간단히 말해서 SMR 드라이브는 오늘날의 기존 HDD처럼 호스트의 모든 요청을 관리합니다. 드라이브 관리형은 SMR을 인식하는 호스트가 필요하지 않다는 장점이 있습니다. 드라이브 관리형 SMR은 거의 모든 것과 호환되므로 배포가 가장 간단합니다. 기본 SMR HDD의 구역화된 특성은 호스트에서 완전히 숨겨집니다. 이것은 이 글을 쓰는 시점에서 SMR 드라이브를 지원하는 상용 OS 또는 파일 시스템이 없기 때문에 초기 소비자 시장 릴리스에서 일반적으로 사용할 수 있을 것으로 예상되는 SMR 관리 유형입니다. 그러나 더 많은 테스트가 수행되고 SMR 기술이 더욱 보편화됨에 따라 SMR을 지원하는 널리 사용 가능한 OS 및 소프트웨어 스택을 보게 될 것입니다.
관리되는 드라이브의 단점은 드라이브가 IO 요청에 관계없이 필요할 때 백그라운드 프로세스를 처리하기 때문에 성능을 예측할 수 없다는 것입니다. 또한 인바운드 임의 쓰기가 호스트 측에서 순차적 쓰기로 병합되지 않기 때문에 드라이브가 더 많은 압박을 받고 있으므로 호스트가 SMR을 인식하는 경우보다 지속적인 작업 부하에서 성능이 저하됩니다. 드라이브 관리형 SMR 드라이브는 디스크에 쓰기 전에 임의 쓰기를 관리할 수 있는 일종의 "랜딩 존"을 활용하여 이러한 단점에 대처합니다. SMR 드라이브에 이 공간을 통합하는 방법은 매우 다양할 수 있으므로 각 드라이브 및 제조업체의 목표 시장에 따라 성능 프로필이 크게 달라집니다.
호스트 관리
다음 유형의 관리는 호스트 관리라고 합니다. 이러한 유형의 관리를 통해 호스트는 명령 및 영역 정보를 사용하여 쓰기가 영역 내에서 항상 순차적으로 이루어지도록 IO를 관리함으로써 SMR 드라이브의 동작을 최적화합니다. 호스트가 영역 내에서 비순차적 쓰기를 보내면 드라이브는 이를 거부하고 오류를 반환합니다. 이것은 드라이브에 더 예측 가능한 성능을 제공하고 초기에 엔터프라이즈 및 하이퍼스케일 애플리케이션에서 볼 가능성이 더 큽니다.
호스트 관리의 단점은 SMR 드라이브가 SMR을 인식하지 못하는 호스트 시스템(HBA, 장치 드라이버, 파일 시스템, 데이터베이스 등)과 호환되지 않는다는 것입니다. 즉, SMR 드라이브를 지원하려면 파일 시스템을 조정해야 합니다. 이것은 세계에서 가장 큰 플레이어가 SMR을 처리하기 위해 스토리지 스택을 수정할 수 있는 능력을 가진 하이퍼스케일 공간에서 처음 발생하고 있으며 현재는 주류 오픈 소스 공간에서도 발생하고 있습니다. xfs 관리자인 Dave Chinner는 XNUMX월 초 보스턴에서 열린 Linux Vault 컨퍼런스에서 xfs에 대한 SMR 최적화를 설명하는 문서를 게시했습니다. 동일한 이벤트에서 Suse의 Hannes Rienecke는 현재 파일 시스템이 호스트 관리 SMR 드라이브와 함께 작동할 수 있도록 하는 영역 캐싱 메커니즘을 제시했습니다. 용량에 대한 욕구와 함께 이러한 투자는 다른 사람들이 새로운 오픈 소스 솔루션을 채택하고 SMR 드라이브를 지원하기 위해 시스템 수정을 추구하도록 장려할 것입니다.
호스트 인식
최종 관리 유형은 호스트 인식으로 알려져 있습니다. 간단히 말해서 호스트 인식은 위의 두 가지 관리 유형의 조합입니다. SMR 드라이브는 자체 관리되지만 새로운 ZBC/ZAC 표준을 구현하고 호스트가 새로운 명령 집합을 사용하여 드라이브 동작을 최적화할 수 있습니다. 이 경우 드라이브가 호스트로부터 비순차적 쓰기를 수신하면 요청을 수락하지만 요청의 성능을 예측할 수 없습니다. 호스트 인식은 이전 버전과 호환된다는 이점이 있으며 호스트에 일부 제어 권한을 부여합니다. 호스트 인식은 모든 드라이브 관리 배포를 대신하여 대부분의 클라이언트 및 기존 엔터프라이즈 시스템에 대한 선택 모델이 될 가능성이 높으며 호스트 관리는 최신 분산 스토리지 솔루션에 대한 선택으로 나타나기 시작했습니다.
SMR(Shingled Magnetic Recording)이란 무엇입니까?
