ATA 이야기5

 자, 드디어 대망의 SMART입니다. 제가 굳이 대망이라는 수식어까지 써가며 설레발을 치는 이유는, HDD에서 이 녀석이 차지하는 비중이 상당하기 때문입니다. 얼마나 상당하냐고요? 차차 이야기를 풀어나가도록 하겠습니다.

 SMART Feature Set은, Self-Monitoring, Analysis, and Reporting Technology의 약자입니다. 약자를 보니 좀 감이 오시나요? 말 그대로입니다. 스스로 자신의 상태를 감시하고 분석하고 자신의 상태를 report하는 똑똑한 기술! 그게 바로 SMART feature set입니다. Spec.에서 설명하는 내용을 살펴보기 전에, SMART의 큰 그림과 주요 개념부터 살펴보도록 하겠습니다.

 조금 나이가 되신 분들은, 286 XT 혹은 그 이전 세대의 computer를 사용해본 경험이 있을 것입니다. 저 역시 시작은 286 XT였으며, 최초 소유한 computer는 286 AT에 5.25" floppy disk drive가 두개 달린 당시에는 최고급 사양을 뽐내는 녀석이었습니다. 당시 가격은 40만원으로 대학 등록금보다 비쌌다고 합니다. 그러다가 한 1~2년 있으니 저한테는 없는 HDD라는 장치를 장착한 녀석들이 선보입니다. 기억하실지 모르겠지만, 이 녀석들은 치명적인 단점이 몇가지 있었는데, bad sector/parking 등의 문제가 대표적이었습니다. 언제 bad sector가 날지도 모르고 computer를 끄기 전에 parking command를 날려줘야 하는 번거로움은 많은 사람들이 불편해했으며, bad sector가 나기라도 하면 고가의 HDD를 버리는 일도 다반사였던 것으로 기억합니다.

 이런 문제들이 판을 치니 engineer들이 고민을 하기 시작합니다. Parking과 bad sector 문제야 다른 관점에서 해결이 되었지만, 이 놈의 drive의 상태가 어떤지 알 수 있다면 얼마나 좋을까? Bad sector 등의 문제가 생기기 전에 알 수 있다면 얼마나 좋을까? 등의 해결책을 고민하기 시작하였고 그 고민을 해결하기 위해 나온 것이 바로 SMART feature set입니다. 

 응? 어떻게 SMART로 이 것을 해결할 수 있지?라는 의문이 드실 겁니다. 처음 말씀드린 self-monitoring과 관련된 부분인데, HDD는 자신의 수명과 관련된 여러가지 parameter 들을 실시간으로 수집을 하고 있습니다. 그리고 이 parameter 중에 임계치 값을 넘어가는 경우 불량이 발생하더라라는 그 간의 축적된 개발 경험을 통해 특정 command에 이런 상태를 report하게 됩니다. 이는 보통 computer를 booting할 때 위의 command를 이용하여, parameter 중에 임계치를 넘어가는 녀석이 있나 없나를 drive로부터 넘겨 받고, 만약 넘어가는 녀석이 있다면 화면이 그대로 멈추게 될 것입니다. 물론 이는 전적으로 mainboard 제조사에서 이 기능을 사용할지 말지에 따라 결정됩니다.

 최근 호환성 불량 관련해서 새로운 사실을 알게 되었는데, Win7은 SMART를 이용하여 실시간까지는 아니겠지만 SMART를 이용하는 것이 예전 OS보다는 더 똑똑해진 것으로 보이며, HDD access 시 임계치가 넘어가는 녀석이 있으면 따로 back-up을 할지에 대한 여부를 물어보는 pop-up 창이 뜨더군요. 하지만 이와 관련된 정보를 모르는 일반 사용자들이 얼마나 이 정보를 신뢰할 수 있으며 잘 따라줄지에 대해서는 약간 회의가 들기도 합니다.

 또한 이런 기능도 있습니다. 스스로 자기 자신의 상태를 test 및 check 해볼 수 있는 것이 바로 그 것입니다.. 신기하지 않나요? Command 하나면 자신의 상태를 스스로 검사해보고 이상 유무를 알려준다라... 이게 바로 SMART의 self-test의 가장 큰 이점이 아닌가 싶습니다. 실제 대형 OEM 들은 자신의 computer 생산 과정에서 SMART self-test 기능을 이용하여 조기 불량을 검출하고 있습니다.

 실제 SMART feature set을 지원하는지에 대한 여부는 Identify table에 명시하고 있으나, 요새는 거의 enable되어 있다고 보면 됩니다.

 그럼, 실제 이 녀석을 사용하고 분석하기 위해 필요한 세세한 것들을 한 번 알아보겠습니다.

 SMART data structure는 device의 예약된 공간에 저장되어 있는데, 이 예약된 공간과 structure의 세부 구조는 HDD의 제조사별로 관리하는 방법과 형태가 조금씩 다릅니다. 공통점이 있다면, HDD는 크게 두 영역으로 나눌 수 있습니다. 첫 번째 영역은 사용자가 사용가능한 user data 영역이고 두 번째는 HDD 제조사가 동작에 필요한 정보를 media의 특정 부분에 제한을 걸어놓고 HDD F/W 내부적으로만 접근 가능하도록 예약해놓는 부분이 바로 그 것입니다. SMART data structure는 이 예약된 공간에 적힙니다. 흔히 대형 computer 제조사들은 복원 solution을 특정 partition을 할당하여 제공하는데, 이는 위에서 말한 예약된 공간과는 다른 영역입니다. 제조사에서 할당하는 partition은 첫 번째 영역을 쪼개서 사용하는 것입니다. 어찌됬건 양도 많고 굉장히 세세하기까지한 SMART data는 사용자 영역이 아닌 공간에 적힌다는 것만 알아두시면 되겠습니다.

 SMART가 data를 수집하는 방식에는 on-line mode와 off-line mode 두 가지가 있는데, spec.에서 말하는 두 방식의 차이는 data를 수집하는 동안 drive 성능에 영향을 주냐 안주냐인데, 실시간으로 수집되는 정보는 거의 on-line이라고 보면 됩니다. On-line 방식은 성능에 영향을 주지 않고 후자는 반대인데, 후자의 방식으로 data를 수집하는 item은 제가 알기로는 거의 없는 것으로 알고 있습니다. 요샌 CPU clock도 예전에 비해 꽤 고성능이라 배열에 값 한 두개 때려 넣는다고 해서 성능이 낮아질리는 없겠죠? 그러니 간단하게 넘어가도록 하겠습니다.

 다음으로 SMART를 볼 때 attribute라는 단어를 심심치 않게 보게 될 것인데, 이는 SMART가 수집하는 data 각각을 나타내는 것입니다. 그럼 이 data에는 어떤 것들이 있느냐 하는 것은 아래 command를 하나 씩 살펴볼 때 설명하도록 하겠습니다.

 만약 device가 SMART feature set을 지원한다면 아래 command들은 반드시 지원해야 한다고 합니다.

 − SMART DISABLE OPERATIONS

 − SMART ENABLE/DISABLE AUTOSAVE

 − SMART ENABLE OPERATIONS

 − SMART RETURN STATUS

 또 선택적으로 아래 command들을 지원할 수도 있다고 합니다.

 − SMART EXECUTE OFF-LINE IMMEDIATE

 − SMART READ DATA

 − SMART READ LOG

 − SMART WRITE LOG

 − READ LOG EXT

 − WRITE LOG EXT

 그러나, 제가 초반에 밝혔는지는 모르겠지만, 이놈의 대형 OEM들은 spec.에 있는 것들은 거의 다 지원되길 바라기 때문에 현존 5개의 제조사들이 생산하는 HDD들은 모두 위 command들을 지원한다고 보시면 됩니다.

 그럼 하나 씩 살펴볼까요?

 일단 SMART command set은 아래와 같이 생겼습니다.

 <그림 1.SMART Feature register values>

 살펴보기에 앞서, SMART command들은 command code를 B0h를 사용하며, sub-command set은 Feature Register로 관리합니다. 위에서 언급한 SMART 관련 command들 중에 SMART로 시작하는 녀석은 모두 B0h:XXh로 command가 나가고 READ/WRITE LOG 계열은 command code가 다르니 참고하시기 바랍니다. 그리고 SMART command set은 특징이 하나 있다면, command를 보낼 때 LBA Mid는 4Fh, LBA High는 C2h로 반드시 set해서 TFR set을 구성해야 한다는 것입니다. 만약 Command와 Feature register만 해당 값으로 채워서 보낸다면 device에서 error처리를 할 것이니 주의하시기 바랍니다.

 우선 SMART DISABLE command는 아주 쉽습니다. SMART 기능을 끌 때 사용합니다. SMART는 device 동작 상에 도움이 됬으면 됬지 해로운 기능은 아니기에 이 command를 쓸 일은 거의 없을 것이겠죠? 아직까지 OEM에서 ATA protocol 검증을 위한 호환성 tool에서 사용하는 경우는 봤지만, 실제 사용상에 있어 이 command를 사용하는 경우는 보지 못했으니 가볍게 넘어가도록 하겠습니다.

 SMART ENABLE/DISABLE AUTOSAVE는 이름에도 나와 있듯이 autosave 기능을 control할 때 사용합니다. Disable을 하기 위해서는 sector count를 0로 enable하기 위해서는 F1h로 채워서 command를 보내면 됩니다. 그럼 autosave란 무엇일까요? 간단하게 설명하자면, 실시간으로 data를 수집하기는 하는데 이게 성능에 영향을 주지 않게하기 위해선 어떤 방법을 써야 할까요? 네 맞습니다. Buffer에 그냥 계속해서 저장하기만 하면 됩니다. 그런데 buffer에 저장 해놓고 어느 순간 power를 끄지 않는다면 어떻게 될까요? 다 날아가버리겠죠? 그래서 일정 주기로 이 data를 device에 save를 하는데 이러한 기능을 autosave라고 합니다. 이런 data들은 위에서 말한 제조사에서 특별히 할당한 공간에 write됩니다.

 SMART ENABLE command는 disable과 개념만 반대이니 이 것도 간략하게 넘어가겠습니다.

 여기까지는 참 쉽죠잉~(개그였습니다... ^^;;)

 SMART RETURN STATUS command는 위에서 살짝 언급했던 녀석인데, 이 command를 보내면 device는 자신의 상태를 나타내는 지표인 각각의 attribute들을 검사하여 임계치를 넘어간 녀석이 만약에 있다면, 난 굉장히 상태가 좋지 않다라고 그러니 새로운 걸로 바꿔라라는 의미로 일반 output과는 다르게 TFR set을 만들어서 보냅니다. 모든 SMART command들은 Command와 Feature register 외에 LBA Mid/High register에 특별한 signature를 실어서 보낸다고 했었는데, 그걸 뒤바꿔서 report합니다. 만약 임계치가 넘어간 attribute가 한 개도 없는 경우는 보낼 때와 마찬가지로 4Fh/C2h로 응답하지만, 한 개라도 넘어가는 녀석이 있는 경우에는 이를 뒤집어서 F4h/2Ch로 응답하게 되어 있습니다. 번외로, SMART attribute 모두가 임계치를 넘어가느냐 안넘어가느냐를 검사하지는 않는다는 것을 알아두시기 바랍니다. 각 제조사 별로 attribute의 개수가 다르지만 보통 30개 이내인데 이중에 실제 임계치를 검사하는 녀석은 5개 내외로 굉장히 적은 편입니다. 제 생각인데, OEM이 요구해서 개수를 늘려 놨는데 막상 이 녀석들의 임계치를 정하기가 애매해서 경험치로 몇몇 녀석만 검사하는 것으로 보입니다. 일례로 HP의 경우 이들이 관리하는 HP SMART spec.이 따로 있을 정도로 굉장히 까다로운데 이들도 임계치를 검사하는 개수가 5개 이내입니다. 힘들여서 만들어 놓았더니 별 관심을 갖지 않는 것, 개발자라면 누구나 하는 갑에대한 한탄이겠죠?

 으... 이제 슬슬 양이 많은 녀석들로 넘어가겠네요...;;; 갑자기 귀찮아지기 시작했습니다...

 SMART EXECUTE OFF-LINE IMMEDIATE는 SMART에서 제공하는 self-test를 수행하라는 command입니다. 각각의 self-test는 LBA low register를 사용하여 선택하는데 아래와 같습니다. 간단하게 80h가 or되었느냐 안되었느냐로 mode를 구별할 수 있습니다.

<그림 2. SMART EXECUTE OFF-LINE IMMEDIATE LBA Low register values>

 Spec.에서 설명하는 test 종류는 ATA7을 기준으로 mode에 따라 두 가지가, 종류에 따라 네 가지가 있습니다. Mode는 off-line mode와 captive mode 등이 있습니다. Off-line mode는 data 수집에서 말하는 off-line mode와는 좀 다른 의미로 사용되는데, off-line mode로 수행될 때는 특정 command를 받을 수 있는 반면에, captive mode는 self-test 진행 도중에 어떤 command도 받을 수 없다는 차이점이 있습니다. 왜 굳이 off-line mode와 captive mode로 구분을 해놓았을까요? 원래의 의도는 off-line mode로 self-test를 진행시키고 중간 중간 host의 request가 있을 경우 잠시 test를 끊고 host에 대해 service 한 다음에 이 것이 끝날 경우 self-test를 다시 진행하는 등의 멋진 control을 의도한 것이 아니었나 생각해봅니다. 그러나 현재에 이르러서는 이러한 지식에 대한 전문가의 숫자도 예전만 못하고 또한 기본 개념은 좋았지만 굳이 그렇게 까지 host 쪽 programming을 복잡하게 해봐야 복잡도에 비해 얻는 이익이 미미할 뿐만 아니라, 굳이 off-line mode를 쓰지 않고 captive mode를 써도 쉽게 풀어나갈 수 있기에, SMART feature set에 대한 spec. protocol 검증용으로 test 할 뿐 실제 OS나 device에서 사용하는 경우는 없었던 것 같습니다. Spec에 off-line mode로 self-test를 돌려 놓고 RESET, SLEEP 등과 같은 command로 test를 끊고 다시 resume 시키고 초기화하는 등의 방법등에 대한 기술을 해놓고 있지만, 제가 봤을 때는 사용도 측면에서는 거의 0에 가까운 것 같습니다.(제가 설명하기 귀찮아서 가볍게 설명하고 넘어가는 것이 아니라는 변명을... 하고 싶네요.. ^^;;;)

 위에서 네 가지 종류를 언급했는데, 각각 short, extended, conveyance, seletive 등이 있습니다. Short test는 말 그대로 짧게 간단하게 test를 하는 것인데, 제한 사항이 2분 이내에 끝내야 한다는 것입니다. 어디서 최초로 이를 제안한 것인지 모르겠는데, 현재 대세로 굳어가는 것 같습니다. 2분이라는 시간은 HDD 전체, 특히나 고용량화되어 있는 현 시점에서는 정말 발톱의 때만큼 밖에 test를 하지 못한다는 단점이 있습니다. 이를 보완하기 위해 extended test가 있는데, 흔히 long test라고 부릅니다. 이는 전영역을 read scan해서 사용자 영역 전체를 검사하여 error가 있는지 없는지를 검사하기 위함입니다. Conveyance test는 short test는 뭔가 좀 아쉽고 long test는 소요 시간이 너무 길다는 단점이 있기에 이를 보완하기 위한 목적으로 만들어진 것으로, 전영역을 scan하되 일정 간격을 두고 skip해가면서 scan한다는 차이가 있습니다. 이 skip 간격은 sector count register로 조절하는데 이 간격은 제조사마다 다르므로 제조사의 spec.을 참조하시면 됩니다. Seletive test는 좀더 똑똑한 방법으로 test를 하는 방법인데, test할 영역의 start LBA와 test span을 지정해 주면 지정한 span의 갯수 만큼의 영역에 대하여 scan을 하는 것입니다. 전자의 세 가지 방법이 test 영역을 선택할 수 없는데 비해, 이 방식은 user가 원하는 영역을 선택하여 test할 수 있다는 장점이 있습니다. 각각의 test span은 SMART WRITE LOG command를 이용하여 지정할 수 있는데 이는 이 command를 살펴볼 때 설명하도록 하겠습니다.(까먹을 수도 있습니다...;;;)

 헥헥...

 이 말을 쓴다는 것은 슬슬 지겹고 지친다는 뜻이겠죠? 한 동안 ATA 이야기에 대해 등한시하고 있었는데, 몇몇 분이 기다린다는 댓글을 남기셔서 다시 시작하게 되었습니다. 양 자체가 워낙 많아서 한 방에 쓰기엔 힘이 부치고 또 슬슬 힘도 떨어지고, 무엇보다 빨리 집에 가고 싶은 마음에, 오늘은 여기까지 하겠습니다.

 또 언제 시작할지는 모르겠지만, 최대한 빨리 연재 하도록 하겠습니다.

 더불어 미약한 제 글을 읽어 주신 모든 분께 감사드리며, 늦었지만 새해 복 많이 받으세요~