ATA 이야기6

아하하...
 정말 오랫만에 다시 씁니다. 회사가 팔려가는 입장이라 마음이 뒤숭숭한 것은 전혀 핑계가 아니고, 누가 이런 글을 보겠냐는 생각에 게으름 피우느라 잠시(?) 쉬었습니다. 이제 회사 매각에 대한 정리도 어느 정도 되가는 편이고, 또 놀다가 지쳐서 뭔가 시간 때우기 좋을 만한 꺼리를 찾다가 발견하여 다시 시작하는 것이 아님을 강조하는 바입니다.

 너무 오래되서 제가 어디까지 썼나 되뇌어 봤는데 제가 써놓고도 중구 난방이라 이어 쓰기가 상당히 어렵네요. 대충 보니 SMART Read Data command부터 이어가면 될 듯 싶습니다.
 SMART Read Data command는 이름에서 알 수 있듯이 device가 수집한 SMART 관련 data를 읽어올 수 있는 command입니다. 개념은 아주 쉽습니다. Device는 lifetime 동안 수집한 data를 특정 형식으로 누적 관리하고 위 command가 오면 data를 전송해 주면 됩니다. 여기서 말하는 data 형식은 아래 표와 같이 생겼습니다.

 <표 6-1. Device SMART data structure>

 첫 번째 item(0 ~ 361)은 vendor specific이라 되어 있는데, 이 녀석들이 거의 핵심입니다. 말은 vendor specific이라고 되어 있지만, 누차 강조한대로 대부분의 제조사가 몇 안되는 대형 OEM에 납품을 하고 있기 때문에, 동일 OEM의 computer 제품을 구입한다면 이 녀석들의 각 ID 번호와 내용이 동일합니다. 이 공간에 들어가는 녀석들은 SMART attribute라고 부르는데 각각 ID number와 속성, status, worst value, current value, raw value 등의 값을 가지고 있습니다. 여기서 worst value, current value 등은 각각 고유 계산식이 있어서 직관적으로 파악하기는 어렵고 실제 유저가 보고 직관적으로 이해할 수 있는 값은 raw value입니다. 으잉? 그런데 이상하지 않나요? table 어디를 봐도 제가 말씀드린 하위 항목에 대한 설명이 없지 않습니까? 이건 제조사마다 제공 spec이 있으니 제품 manual을 참조하시면 됩니다. 시중에서 쉽게 구할 수 있는 bench mark tool 중에는 이 녀석들을 분석해서 보여주기도 하더군요. 분석해보면 현재 자신의 device 상태가 어떤지 쉽게 파악할 수 있습니다. Server 업체의 경우 device의 교체 시점을 이 data를 가지고 자체 분석하여 결정하기도 하는데, 이런 업체는 정말 고급 인력이 상주할 가능성이 높다고 볼 수 있겠습니다. 현재는 이 attribute의 갯수는 최대 30개 정도 됩니다.
 두 번째 item(362)은 이전 글에서 언급한 self test의 진행 상황 또는 종료 상황 등의 정보를 담고 있습니다. 각각의 의미는 아래와 같습니다.

 <표 6-2. Off-line data collection status bute values>

 간단한 내용이니 그냥 넘어가도록 하겠습니다.
 세 번째 item(363)은 self test의 세부적인 상태를 보여줍니다. 이것도 표에서 상세하게 설명하고 있으니 그냥 넘어가도록 하겠습니다.

 <표 6-3. Self-test execution status values>

 네 번째 item(364 ~ 365)은 self-test를 long mode로 실행시켰을 때 총 소요 시간을 보여줍니다. 이 값은 HDD의 경우 어디까지나 drive의 총 cylinder와 head 수에 따라 결정되기 때문에, drive의 세대나 disk 수와 용량에 따라 달라짐으로 정확한 값을 말하기는 어렵습니다. 그러나 이 값을 어떤 용도로 활용할 수 있냐면, 자신의 drive를 low format 같은 전영역 write를 하고 싶은 경우 시간이 얼마나 걸릴까가 궁금하다면, 이 값으로 대충 유추가 가능하니 참고하시기 바랍니다.
 다섯 번째(366)는 건너뛰고, 여섯 번째(367)는 해당 device가 self test의 세부 항목 등이 지원이 되는지 안되는지의 정보를 담고 있습니다. 대부분 구현이 되어 있다고 봐도 무방할테니 이부분도 가볍게 pass~
 여섯 번째(368 ~ 369)도 간단한 것으로, 첫 번째 bit은 device가 power saving mode로 진입 시 SMART data를 save할 것이냐의 여부를 결정하는 것이고 두 번째는 SMART ENABLE/DISABLE, AUTOSAVE를 지원하는지의 여부를 가리킵니다. 사실상 두 bit은 모두 set되어 있다고 보는 것이 맞을 것 같습니다.
 일곱 번째(370)는 표에 설명이 되어 있으니 넘어가겠습니다. 모든 device는 error logging 기능을 지원한다고 보시면 됩니다.
 여덟 번째부터 열 번째(372 ~ 374)는 각각의 test에 대한 최소 polling time을 보여주어야 하나 뭐 거의 사장되는 item이라고 보시면 됩니다. 다른 제조사는 이 값을 제대로 표시하는지 모르겠네요.
 이후 item은 별 의미가 없으니 pass~!

 그럼 다음으로 SMART READ LOG command로 넘어가보겠습니다.
 Device는 망할 OEM의 입김이 작용한 spec.이 지정한 여러가지 log를 남겨야만 합니다. 잠시 하소연을 하자면 이 놈의 log들 때문에 code는 복잡해지고 쓰잘데기 없는 정보도 알아야 해서 개발자 입장에서 보면 정말 마음에 들지 않는 기능입니다. 그렇다고 그네들의 입김에 의해서 만들어졌을지도 모를 이 log들을 그들이 잘 분석하느냐하면 그 건 또 아니거든요. 실제 이 log를 가지고 불량 분석은 제조사에서 해서 설명을 해줘야 그네들은 그제서야 끄덕끄덕합니다. 어딜가나 갑은 참 답이 안나오는 것 같습니다.
 다시 본론으로 돌아와서, 이런 log들과 연관 command는 네 가지가 있습니다. SMART READ LOG, SMART WRITE LOG, READ LOG EXT 그리고 WRITE LOG EXT command가 그 것입니다. Read 계열은 읽어오는 것이고 write 계열은 device에 쓰는 것입니다. Read는 양이 많으니 일단 write 계열만 간단하게 설명하겠습니다.
 Write 계열은 어떤 용도로 있냐면, log 중에 host vendor specific이라는 녀석이 있습니다. 이 녀석이 device의 user 영역이 아닌 곳에 write를 할 수 있는 유일한 command입니다. 이 녀석을 어떻게 이용하냐면, OEM들이 그네 들의 고유 정보를 device에 기록하고 싶은데 user 영역에 적으면 user access에 의해 언젠가는 지워질 가능성이 있겠죠? 그리고 적었다치더라도 일반적인 user가 이런 command를 알아서 자유자재로 사용할 가능성도 극히 낮겟죠? 그러니 한 번 적으면 device가 완전 파손되기 전까지는 해당 정보를 유지할 수 있겠죠? 이러한 목적을 가지고 고유 정보를 남기는데 사용합니다. 어떠한 정보가 적히는지는 저도 잘은 모르겠으나, 제가 지금까지 경험해본 대형 OEM들 중에 딱 한 곳이 이 곳에 정보를 적어 사용하였습니다.
 그럼 양이 많은 read 계열로 돌아와 본론으로 들어가기 전에 간단한 개념부터 말씀을 드리겠습니다. 기본은 이렇습니다. 책을 보면 첫 부분에 대부분 목차가 있지 않습니까? 원하는 내용이 어디있나를 보고 싶을 때 목차를 보고 해당 위치를 찾아가듯이 log의 구성도 이와 같습니다. 일단 아래 표를 보시죠.

<표 6-4. Log Address Definition>

 Read 계열의 command는 parameter로 log address와 어디서부터 얼만큼 읽어올지를 넘겨주게 되어 있습니다. Device는 read 계열의 command를 받으면 log address와 start page부터 얼마만큼 넘겨줘야 하는지를 보고 해당하는 data를 전송하는 방식이죠. SMART READ LOG와 READ LOG EXT command의 차이는 시작 offset을 줄 수 있냐 없냐의 차이만 있다고 보시면 됩니다. 으잉? 왜 시작 offset이 필요하나구요? 그러게 말입니다. 어짜피 전체를 다 볼 것이면서 굳이 저런 자잘한 기능을 요구하는지 저도 잘 모르겠습니다. 일단 log page는 512byte가 한 page가 되고 offset도 이 page 단위로만 줄 수 있다는 것을 참고하시기 바랍니다.그럼 하나씩 살펴볼까요?
 00h는 Log directory라 되어 있네요. 이 녀석은 device가 어떠한 log item들을 가지고 있는지에 대한 정보를 보여줍니다. 위에서 설명한 목차 개념이죠. 각각의 item들의 log address와 크기 정보를 제공합니다. 이건 위 표에도 명시가 되어 있으니 참 쉽죠?
 02h는 Comprehensive SMART error log라고 되어 있네요. 명칭은 영어라 뭔가 있어보이지만, 실은 간단합니다. SMART feature set이 적용되고 나서 device는 host command에 대해 어떤 error가 발생하면 이를 logging해야 됩니다. 그리고 이렇게 logging된 item들은 read log 계열의 command로 조회를 해볼 수가 있는 것이죠. 그런데 아쉽게도 일반 user의 경우 이 data를 분석하기가 만만치가 않습니다. 또한 제조사마다 다른 format을 가지고 있으므로 한개를 해독했다고 해도 나머지에 적용하기가 어렵기 때문입니다. 그냥 이런 기능이 있다고만 보시면 될 것 같습니다. 이런 용도로는 써먹을 수 있겠죠. 만약 drive에 문제가 있어 이 log page를 뒤져봤더니 뭔가 있었다. 이를 근거로 제조사에 책임 추궁을 하려하는데 제조사는 얼렁뚱땅 넘어갈려고 한다. 당신네 drive의 SMART error log에 뭔가가 남아있는데 왜 발뺌을 하느냐! 정확한 원인 분석과 대책을 작성하여 보고하라!!! 라는 식으로 말이죠.
 03h는 02h와 동일한데 앞에 뭔가 수식어가 더 붙어있네요. 수식어 대로입니다. 앞서 설명을 했는지 모르겠지만, command 등에 extended가 붙어 있으면 이는 대부분 48bit address 지원을 위한 확장 command가 되겠습니다. SMART error log 역시 마찬가지로 28bit address mode command와 관련된 error logging을 위해 format을 짰더니 48bit address mode command를 지원할 때 문제가 생긴겁니다. 그래서 아예 48bit을 위한 log를 따로 만들었죠. 02h와 내용면에서는 거의 똑같고 address만 확장된거라고 보시면 됩니다.
 위와 같은 맥락으로 06h와 07h를 한꺼번에 설명하자면 말 그대로 self-test와 관련된 logging을 하는 item입니다. 이 역시도 간단하게 설명하고 넘어가자면, SMART self test를 하면 해당 test에 대한 정상 완료 여부, error가 발생했으면 어디서 발생했고 대략적인 원인에 대한 정보를 logging하도록 만들어져 있습니다. Self test 자체가 일반 user가 사용하는 경우는 거의 없고 대형 OEM들이 자기네들 내부 공정 중 돌려보며 불량 사전 검출 목적으로 사용되며, 불량이 발생하면 자기들이 분석하는 것이 아니라 제조사로 보내 결국 저 같은 사람들이 분석하게 됩니다. 즉, 판매되는 제품은 깨끗한 제품이니 그냥 믿고 쓰셔도 됩니다. ^^
 10h ~ 17h는 SATA를 위해 예약된 곳이라 되어 있는데, 여긴 OEM의 SATA관련 log를 추가해봐라라는 압력 또는 우리 제조사는 이런 것도 logging한다는 기술적 자신감으로 있는 item으로 마찬가지로, 담당 engineer만 보는 것이라 생각하면 될 것 같습니다.
 20h는 이름은 거창하게 performance를 언급하고 있지만, logging되는 정보는 간단합니다. HDD 기준으로 설명드리자면, HDD는 zone이라는 개념을 사용하는데 disk 평면을 어떤 기준에 의하여 잘게 구분합니다. 그리고 그 zone 별로 sector의 밀도가 다르죠. 밀도가 높은 곳은 전송 속도가 빠르고 밀도가 낮은 곳은 전송 속도가 낮습니다. 이러한 밀도 정보와 단위 sector에 대한 속도 정보 그리고 seek performance 정보를 logging합니다. 아.. 이건 연속적인 item이 아니니 한 번 기록된 정보가 계속 유효하게 사용됩니다.
 21h와 22h는 각각 READ/WRITE STREAM command 계열의 error 정보를 기록합니다. 그런데 사실 모든 host command에 대한 error 정보를 SMART error log에 남기기 때문에, 여기에 남는 정보는 위치와 status/error 정보로 비교적 단순한 data만 남습니다.
 23h는 spec.에는 있지만 저는 구경도 해보지 못한 녀석이라 설명드리기가 어렵겠네요.
 이하 A0h ~ BFh 까지의 host/device vendor specific은 각각의 입장에서의 고유 정보를 남기기 위한 용도로 사용한다고 보시면 되겠습니다.

 하악하악. 정말 양이 많지 않나요?(사실 조금 적은 감이 없지 않아 있군요...) 사실 이것도 귀찮아서 빼고 게을러서 빼고 해도 이정도나 됩니다. SMART라는 녀석을 일반 user들도 많이 알아 device의 품질 개선을 위해 끊임 없는 claim을 제기해준다면 개발자들은 죽어나겠죠? 그래서 이렇게 복잡하게 만들었나 봅니다. 게다가 영어로 쓰여져 있어 귀찮은 사람들은 안볼테니 더욱 감사할 따름입니다.
 오늘은 여기까지만 하겠습니다.
 사실 지금 회사가 팔려서 오늘 내일 하는 입장이라, 언제까지 제가 이 주제를 이어갈 수 있을지 장담할 수 없지만, 시간이 허락하는 동안에는 최대한 제가 아는 내용을 공유토록 하겠습니다.
from http://sutdaeng.egloos.com/3767993

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 이야기에 대해 등한시하고 있었는데, 몇몇 분이 기다린다는 댓글을 남기셔서 다시 시작하게 되었습니다. 양 자체가 워낙 많아서 한 방에 쓰기엔 힘이 부치고 또 슬슬 힘도 떨어지고, 무엇보다 빨리 집에 가고 싶은 마음에, 오늘은 여기까지 하겠습니다.

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

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

ATA 이야기4

아무도 기다리고 있지 않았던 ATA 이야기 4편입니다.
 신규 model 개발로, 정신없이 7월 초까지 개발에 매진하다가 겨우 정신을 차려보니 벌써 오늘이더군요.  Blog에 독후감을 쓰러 갔다가 반가운 댓글을 보고 난 후 귀차니즘을 극복하고 쓰고 있는 중입니다. '댓글은 나의 힘!'이라는 말을, 평소 의미있게 받아들이지 않았었는데, 오늘 달린 댓글이 힘을 불어넣어주네요~
 그럼 시작하겠습니다~
 휘비고~
 오늘 다룰 내용은 Security Mode Feature Set입니다.
 이 녀석은 저와 같은 firmware 개발자들은 정말 싫어하는 단순 노가다성 작업을 만들어 내지만, 사용자나 특정 기업들은 좋아하는 이율배반적인 녀석입니다. 특히나 IT 업계의 공룡 HP는 유독 이 feature set과 관련된 까다로운 요구사항이 많은데, HP 때문에 이걸 구현해야하나라는 생각이 들 때가 많이 있습니다. 물론 지금이야 아예 이 녀석과는 안녕을 해버렸지만, 예전에 test에서 불량이 발생하여 firmware 이곳저곳을 수정해야만 했었던 적이 있었는데, 정말 싫었었습니다. 다시는 쳐다보기도 싫었던 녀석인데, 이렇게 글을 쓰고 있다니 참 세상은 재미있는 것 같습니다.
 전체적인 내용을 요약하여 말하자면 아주 간단합니다. 암호를 설정하고 남이 못쓰게 잠궈버리는 기능이 전부입니다. 이렇게 잠긴 상태에서 이걸 풀어야 하는데 은행 ATM처럼 몇회 이상 암호 입력이 틀리면, 놀라지 마세요~! 사용자 data 영역 전체를 지워버리는 아주 무식한 기능까지 갖추고 있습니다.
 작년인가 Segate인가 Intel SSD에서 firmware 오류로 사용자 암호를 설정하면 data가 지워지는 문제가 있었는데, 십중팔구 firmware engineer가 요쪽 code에 bug를 심어놨을 가능성이 다분합니다.
 여기서 잠깐 간단한 HDD 상식에 관련된 이야기 하나 할까요? 위에서 말씀드린 지운다는 것은, HDD 입장에서는 의미없는 data pattern으로 해당 영역을 다시 써버린다 쯤 되겠습니다. 즉, HDD에서는 사전적인 의미의 지운다라는 동작은 없다라는 것입니다. 그럼 digital device에서 의미없는 pattern이란 무엇일까요? 뭐 간단하지 않겠습니까? '0x0000' 이거나 '0xFFFF' 등이겠죠. 이 pattern은 제조사 마음대로인 것 같습니다.
 다시 본론으로 돌아와서, Security Mode Feature Set을 이해하기에 앞서 왜 Security가 아닌 Security Mode인지를 생각해보시면 더 쉽게 이해하실 수 있을 겁니다. 왜 굳이 mode라는 단어까지 사용했냐면, 암호 설정 관련된 부분과 암호 설정 여부에 따라 기타 다른 command가 들어왔을 때에 어떻게 처리할지를 관리하기 위한 부분, 이렇게 크게 두 가지로 나누어져있는데, 전자가 Security에 해당하고 후자가 Mode에 해당한다고 보시면 됩니다.
 그럼 하나씩 살펴볼까요?
 우선 암호는 우리가 흔히 BIOS에서 볼 수 있는 user password와 master password 두 가지 종류가 있습니다. Master는 제한적인 경우에 사용합니다. 예를 들어 user password를 잊어 먹었을 때, 잠겨있는 HDD의 상태를 풀어서 다시 변경할 때, 나 이 HDD의 쥔장이다라는 것을 인증하기 위한 것으로 전체적인 동작에 큰 영향을 미치지는 않습니다. 실제 Security와 가장 중요하게 관련된 녀석은 user password라고 보시면 됩니다.
 그리고 각 password를 설정할 때 두 가지 level로 설정할 수 있습니다. 그 두 가지는 high와 maximum level입니다. Master password야 high건 master건 별로 상관이 없지만, user password는 이 level 값에 조금 민감하게 반응합니다. High level로 user password를 설정해놓으면 이를 기억하지 못한다고 하여도 master password를 알고 있으면 잠금 상태를 풀 수 있습니다. 그런데 만약 maximum level로 잠궈 버린 상태에서 기억나지 않는다면 이건 답이 없습니다. Maximul level로 user password를 설정하면 master password를 안다고 하여도 해당 drive의 잠금 상태를 풀 수 없도록 spec.에 규정되어 있습니다. 위에서 잠깐 '제한적인 경우'를 언급했는데 그게 바로 이런 경우입니다. 지금 생각해보니 master라는 이름이 아깝네요.
 만약 이런 경우를 만난다면 울며 겨작먹기식으로 data가 모두 날아가는 것을 지켜보든지, 아니면 제조사에 들고 가서 요청을 해야지만 해결할 수 있습니다.
 그럼 Security Mode Feature Set의 양대 산맥인 mode에 대해서도 좀 알아볼까요? 암호를 설정하게 되면 device는 잠겨버리게 되어 있습니다. 이렇게 잠기게 되는 상황을 spec.에서는 좀 더 세분화시키고 있습니다. 일단 아무것도 손대지 않았을 경우를 security disabled라고 합니다. 이 상태에서 특정 command를 받게 되면 enabled 상태가 되고 command 종류의 따라 잠기는 상황이 되는데 이를 locked라고 합니다. 여기까지면 쉽겠는데 또 다른 특정 command를 받게 되면 disabled 상태에서 잠기는데 이를 frozen이라고 합니다. 요약하자면 Security Mode Feature Set에서는 disabled/enabled와 locked/unlocked. frozen/not frozen 등과 같은 mode의 조합을 이용하여 각각의 상황에 맞게 state machine을 제어하게 됩니다.
 사실 요약이 요약이 아닐 정도로 무슨 소린지 모르겠습니다. 밑에 state diagram을 붙여놓고 다시 설명드리겠습니다.

 우선 여기까지 대충 개념은 설명한 듯 하니, 이 녀석과 관련된 command들을 좀 알아보겠습니다.
  - SECURITY SET PASSWORD
  - SECURITY UNLOCK
  - SECURITY ERASE PREPARE
  - SECURITY ERASE UNIT
  - SECURITY FREEZE LOCK
  - SECURITY DISABLE PASSWORD
하나씩 살펴볼까요?
 SECURITY SET PASSWORD command는 user/master password를 설정하는데 사용합니다. 이 녀석은 data-out command로 반드시 512byte를 전송해줘야 합니다. 이 command에 딸려 나가는 data structure는 아래와 같습니다.

ATA spec.에서 오려왔습니다.
Word0는 제가 위에서 설명한 내용에 맞게 채워주면 됩니다. 그리고 실제 암호에 해당하는 녀석은 Word1 ~ 16까지의 32bytes로 여기에 구미에 맞게 채워주시면 됩니다.
Word17은 master passowrd를 설정할 때 채우는 값으로, 채울 때 주의 사항이 있는데 이 값이 만약 0h이거나 FFFFh이면 abort error가 나니 반드시 위 두 값이 아닌 다른 값을 채워줘야 한다는 것입니다.
 참~ 쉽죠잉~
뭐 위의 table의 각각의 항목만 이해하셨다면 일단 이 command는 거의 이해한거나 다름 없습니다. 그럼 거의를 빼고 난 나머지는 무엇일까요? 그건 밑에서 설명드리겠습니다.

 SECURITY UNLOCK command는 SET PASSWORD의 반대 개념이라고 생각하시면 됩니다. 이름에서 풍기는 느낌처럼 device가 locked 상태일 때 이를 풀어서 unlocked 상태로 돌릴 때 쓰는 녀석입니다. 이 녀석도 마찬가지로 data-out command인데 주의할 점이라면 SET PASSWORD로 설정한 암호와 동일한 값을 실어서 보내야지 안그러면 처음에 말씀드린 ATM 사고가 날 수도 있습니다.
 SECURITY ERASE PREPARE command는 좀 재미있는 녀석입니다. ATM 사고라고 제가 살짝 겁을 주기는 했지만 사실 비밀번호가 다 틀렸다고 해서 바로 data를 지우지는 않습니다. 지우기 위해서는 자 지워라'라는 command를 날려줘야 그 때부터 지우기 시작하는 것입니다. 이 녀석은 '자 지워라' command를 보내기 전 마지막 안전장치로 반드시 '자 지워라' command 이전에 보내야 합니다. 이 command 없이 '자 지워라' command를 보내면 device는 '님~ 뭐셈~? 즐~'이라는 반응을 보일 겁니다.
 죄송합니다. 나이를 먹더니 자꾸 썰렁해지기만 합니다.
 어찌됐건 이 녀석은 마지막 안전장치라는 것만 머리속에 집어넣으시면 될 것 같습니다.
 SECURITY ERASE UNIT command가 바로 위에서 언급한 '자 지워라'에 해당하는 녀석입니다. 그런데 이 녀석이 수행하는 역할 자체가 워낙 무시무시한 것이라, 이 command 자체도 안전장치를 가지고 있습니다. 그게 무엇일까요? 이 녀석 자체가 data-out command입니다. 즉, 기존에 설정된 user 또는 master password와 일치해야지만 실제적인 지우는 동작이 시작되는 것입니다. 사실 합리적으로 생각해보면 그렇지 않겠습니까? 만약 일부러 password를 틀리게 command를 보낸다음 이 command를 보내는 것만으로도 data를 지울 수 있었다면 분명 hacker의 먹이감이 되어 난리가 났었을 겁니다. Spec.은 괜히 spec이 아닌가 봅니다. 이 command로 실어 보내는 data structrure는 SET PASSWORD command와는 좀 다르게 생겼습니다.

다른 것이야 다 이해하시겠죠? 뭐 부연설명이 필요한 것이라면 erase mode가 있겠네요. Normal과 enhance의 차이는 무엇일까요? 업무상 기밀이라 요부분은 말씀드리기 애매한 부분인 것 같습니다. 어짜피 지워지는 것은 똑같으니 만약 test 해보고 싶으신 분들께서는 enhanced mode를 추천하고 싶습니다.

 SECURITY FREEZE LOCK command는 딱 보면 감이 오지 않겠습니까? 직역하자면 "Locked/unlocked인 상태로 꽁꽁 얼려버려 아서스!" 정도 될까요?
 아서스는 WOW 하시는 분이면 어느 정도 이해하실 수 있는 농담입니다...
 네... 저는 뉀네입니다...
 뉀네를 모르는 당신은 눼눼~ 우후훗~(지루할 것 같아 살짝...;;;)
 위에서 forzen mode에 대해서 살짝 언급했었는데요, 말그대로 어떤 mode 상태로 얼려버리는 것입니다. 현재 device가 locked/unlocked mode인 상태로 이 command 상태로 frozen mode까지 더해진다면, power를 껐다 키거나 또는 hard-reset이 아니고서는 lock mode 관련해서는 변경할 수 없습니다. 가령 device가 locked mode였는데 이 command를 받고 locked/frozen mode로 진입하면 power/hard-reset을 제외하고는 이 drive의 locked mode를 unlocked mode로 풀 수 없다는 것입니다. 복잡하시죠? 저도 왜 이따구로 만들었는지 담당자가 미울 뿐입니다. 그는 아무래도 철통 보안이라는 title을 따고 싶었나 봅니다.
 SECURITY DISABLE PASSWORD command는 disable이라는 단어가 핵심입니다. 간단하게 설명하자면 현재 설정된 locked mode를 풀고 disabled mode로 다시 돌아오게하는 녀석입니다. 이 녀석도 data-out command로 data structure는 아래 처럼 생겼습니다.

 이 녀석은 단순히 mode 변경만을 위한 것으로, command를 보낸다고 해서 기존의 command가 바뀌거나 하지는 않습니다.

 후아...
 어제부터 틈틈히 작성했는데 벌써 날을 넘겨버렸네요. 일하면서 test 걸어놓고 짜투리 시간에 작성하는 것이라, 문법도 엉망 내용도 엉망이네요. 이해해주시길 바라겠습니다.
 자 어느정도 이 feature set에 관한 개념이 잡히셨나요? 각각의 command와 password, mode에 대한 기초지식은 파악이 되셨으리라 믿고 이번 이야기의 꽃인 state diagram에 대해 살펴보도록 하겠습니다.
 정신 똑바로 차리시지 않으시면 limbo에서 빠져나오실 수 없습니다!(<- Inception은 정말 대박이었습니다.)
 자우선 아래 state diagram을 보시죠. 심호흡 한 번 하시구요~

 우선 시작점을 살펴볼까요? 시작점은 바로 SEC0입니다. 제조사에서 출하된 후 별도의 가공을 거치지 않았다면 무조건 시작점은 SEC0입니다. 예외가 있는데, 특정 회사의 BIOS에서는 요녀석의 상태를 바꾸기도 하는데 그게 어디였는지 기억이 안나는 군요. 만약 BIOS에서 mode를 변경해버렸다면 그 device는 그 system에 귀속되버립니다. 무시무시하죠.

 자...
 SEC0:Powered down/Security disabled 라는 것을 보니 딱 봐도 power가 꺼진 상태이고 이 때는 disabled 상태라는 것을 나타내는 거겠죠? Power on 후에는 무조건  SEC1 상태로 가고 여기서 만약 SECURITY SET PASSWORD command를 받게 되면 SEC5 상태로 가게 됩니다. 여기서 주의하실 것이 SEC5:Unlocked/Not forzen 이라는 문구입니다. SET PASSWORD command를 받았다고 해서 무조건 locked mode로 빠지는 것이 아니라, command를 받고 나서 reset 또는 FREEZE LOCK command를 받아야지만 실제적으로 잠김 상태인 SEC4로 가는 것입니다. SEC4로 가고 나서 별도의 security command 없이 power down이 되면 이후부터 시작점은 SEC3가 되게 되고, 이 때부터는 아무리 power를 껐다키고 reset을 날린다 하여도 SECURITY UNLOCK이나 ERASE UNIT command가 아니고서는 locked mode에서 빠져나올 수 없는 것이죠. 어제는 잠궈버리다는 표현이 적절한 줄 알았는데 오늘 보니 귀속이라는 표현이 딱인 것 같습니다.
 기타 다른 경우의 수도 설명이 필요하신가요?
 위에서 적은 내용을 어느 정도 이해하셨다면 이 state diagram은 가볍게 해석 및 적용하실 수 있으리라 믿겠습니다~!(귀찮아서가 절대 아닙니다....;;;)
 쓰다보니 한가지 빼먹었는데, device가 locked mode일 때는 몇몇 command를 abort시켜버립니다. ATA command 자체가 좀 많아서 간단하게 개념만 말씀드리자면 user data를 read/write 하는 command 계열은 모두 abort 시킨다고 보시면 됩니다. 꼭 그런 것만은 아니나 대충 그렇다는 것입니다. 이와 관련된 table이 있는데 이게 좀 길고 양이 많아서 붙이기가 애매하네요. 에잇! 그래도 혹시 필요하실 분이 있을지도 모르니 붙여드리겠습니다. ATA-7 기준입니다.

 
 아...
 시작할 때는 의욕이 충만했었는데, 시간이 흐를 수록 귀찮아지는군요. 다음 글은 좀 더 내실있고 성실하게 쓸 것을 다짐하며 이번 이야기는 여기서 마무리하도록 하겠습니다.
 다음 편은 SMART Feature Set입니다. 양이 정말 많은데 한 번에 쓸 수 있을지 모르겠습니다...;;;

ATA 이야기3

아무도 궁금하지 않으셨겠지만, 개발 과제의 controller chip이 바뀌면서 정말 많이 바빴었습니다. 항상 느끼는 거지만 hardware가 바뀔때마다 software쟁이들은 정말 매번 피똥 쌀 정도로 바빠지는 것 같습니다. Hardware쟁이님들! 설계 좀 잘해주시길... 이번에도 어쩔 수 없이 workaround code로 넘기긴 했지만 이건 아니잖아요~

 잡설은 이만하고, 이번 글에서는 power management 관련된 feature set에 대해서 이야기를 해보겠습니다.

 ATA의 PM(power management)은 크게 두 가지가 있습니다. SATA로 넘어가면 한 녀석이 더 있는데, 이는 SATA를 다룰 때 이야기하도록 하겠습니다.

 먼저 일반적인 PM feature set에 대해 얘기하자면, device의 동작 상태를 관리하기 위한 것입니다. 동작 상태? 뭐 아주 간단합니다. Device가 열심히 뭔가를 하고 있느냐, 아니면 전력 소모를 줄이기 위해 쉬고 있느냐가 각각의 동작 상태가 됩니다. 뭔가를 하고 있을 때를 active 상태라 하고 놀고 있을 때는 놀고 있는 정도에 따라서 idle, standby 그리고 sleep으로 구분합니다. Active 상태는 굳이 설명하지 않아도 이해가 가시죠? 그럼 idle, standby, sleep은 각각 무엇을 의미하는 것일까요? 쉬고 있는 상태에서 전력 소모도에 따른 단계를 구분해 놓은 것입니다. 쉬고 있는 상태에서의 전력 소모량을 나열해보자면 idle > standby > sleep 순입니다. 그런데 이건 얼마든지 뒤집어 질 수도 있습니다. 왜냐구요? 앞 글에서 썼었지만 ATA 자체가 굉장히 모호하게 기술되어 있기 때문에 제조사 마음대로 뒤집을 수 있습니다. 그러나 대체로, 아니 대부분 위에서 언급한 순서대로 사용되어집니다. ATA의 모호성을 다시 한 번 비판해보고자 살짝 곁들인 양념입니다.

 위의 쉬고 있는 세 단계는 각각의 command로 제어할 수 있습니다. 그럼 PM feature set을 위한 개념들과 command에 대해 알아보겠습니다. 

  - A Standby timer

  - CHECK POWER MODE command

  - IDLE command

  - IDLE IMMEDIATE command

  - SLEEP command

  - STANDBY command

  - STANDBY IMMEDIATE command

 그럼 차례대로 하나씩 살펴볼까요?

 먼저 나오는 standby timer라는 녀석은 host가 command를 주지 않아도 자동으로 standby mode로 들어갈 수 있도록 하기 위해 사용되는 개념입니다. 일반적인 경우에는 전력 소모를 줄이기 위한 각각의 놀고 있는 mode로 진입하기 위해서는 반드시 command가 필요합니다. 그런데 command 없이도 자동으로 standby mode로 들어갈 수 있는데, 그게 바로 이 standby timer가 만료됐을 때입니다. 그럼 언제 timer를 시작할까요? Command를 받고 나서 timer 값 동안 command가 들어오지 않으면 자동으로 standby mode로 들어가게 됩니다. 그런데 이 것이 또 애매한 것이 꼭 command가 들어왔느냐에 의해 좌지우지되지는 않는다는 사실 때문입니다. 이건 제조사에 따라 다르게 가져갈 수 있지만 통상적으로 보면 disk access에 의해 결정됩니다. 아~ HDD라는 놈은 꼭 command가 disk access를 발생시키지 않기에 경우의 수를 따져보면 복잡해지기에, 편의상 command 단위로 설명을 드린 것이니 유의하시기 바랍니다.

 Standby timer 값을 설정할 수 있는 command는 IDLE, STANDBY command 두 개가 있습니다. Timer unit에 대한 설명은 아래 표와 같습니다.

 [그림 1. Standby Timer Periods]

 CHECK POWER MODE command는 이름 그대로입니다. 이 command를 host가 보내면 device는 현재 자신의 PM mode가 어떤 것인지를 알려주게 됩니다. 그런데 제가 몇 년 동안 Windows에서 command I/O를 분석해보니 이 녀석은 거의 사용되지 않더군요. Device driver를 설계 또는 구현한 사람이 이 command의 존재를 알고 각각의 상태를 check하여 효율적으로 PM을 관리해야 하는데 그러는 것 같지가 않습니다. 왜 이렇게 되었느냐를 생각해보니, device 특히 HDD가 너무 똑똑해서 굳이 device의 상태를 check하지 않고 맘대로 command를 날려도 잘 동작하기 때문이 아닌가 싶습니다. 실제 HDD는 굳이 위 command를 받지 않고도 알아서 PM을 수행합니다. 그건 다음의 advanced power management feature set을 이야기할 때 업무상 비밀이 노출되지 않는 범위내에서 이야기하도록 하겠습니다. 최근 JMicron USB controller chip에서 이 command를 사용하는 경우를 보긴 했지만, USB protocol을 모르는 저로써는 왜 주기적으로 굳이 이 command를 보내는지 아직은 100% 이해가 되질 않더군요. 어찌됐든 제가 사용하는 경우를 목격했으니, 이 녀석의 쓰임새에 대해서 좀더 떠들어보겠습니다. Host가 CHECK POWER MODE를 보내면 drive는 자신의 PM status를 check하여 TFR의 sector count 값에 자신의 status를 실어서 응답하는 구조로 되어 있습니다. 각각의 sctor count 값의 의미는 아래와 같습니다.

  - 00h : device is in Standby mode.

  - 80h : device is in Idle mode.

  - FFh : device is in Active mode or Idle mode

 위에서 설명드렸다시피, 현재는 APM이 적용된 시점이기에 standby mode에 있지 않고서는 거의 대부분 idle mode에 있다고 보시면 됩니다. 요것도 제조사 마음대로인지라 제조사별로 idle 상태일 때 어떤 값이 올라올지는 장담할 수 없겠네요...

 나머지 command들은 각각의 세 단계로 진입시키기 위한 command들입니다. Command 명 뒤에 IMMEDIATE가 붙은 것들은 바로 각각의 상태로 진입시키기 위한 녀석들입니다. 응? 갑자기 의문점이 생기지 않으신가요? 바로 진입한다? 네 그렇습니다. 위에서 standby timer를 언급했으니 STANDBY command로 설명을 하겠습니다. 우선 STANDBY IMMEDIATE command를 날리면 device는 짤 없이 무조건 standby mode로 들어가야 합니다. 1초의 망설임도 있으면 안됩니다. 바로바로 들어가야 하지요. 그런데 그냥 STANDBY command를 보내게 되면 상황에 따라 다르게 동작할 수 있습니다. 위에서 언급한 standby timer 값 때문입니다. Timer 값을 0을 주고 STANDBY command를 보내게 되면 이건 IMMEDIATE command와 동일하게 동작합니다. 그런데 timer 값이 0이 아닌 값이면 바로 들어가지 않고 지정된 timer가 만료되었을 때 standby mode로 들어가게 됩니다. IDLE command도 마찬가지로 이 timer 값을 줄 수 있는데 이 때는 timer가 만료되어도 idle mode로 들어가는 것이 아니로 standby mode로 들어간다는 차이가 있습니다. SLEEP command는 IMMEDIATE 구분이 없습니다. 이 command를 받으면 무조건 sleep mode로 들어가야 합니다.

 그럼 여기서 잠깐 idle, standby와 sleep mode의 감이 잘 안오실테니 HDD의 동작 상태로 간략하게 설명을 해보겠습니다. Idle 상태는 HDD의 기구적으로 별다른 변화가 없습니다. Head도 disk 위에서 날고 있고 spindle motor도 돌고 있습니다. 단지 R/W 동작만 수행하지 않을 뿐입니다. 좀더 자세하게 이야기 하면 command가 오면 바로 R/W 동작을 수행하기 위한 만반의 준비를 하고 있되, 전력 소모를 위해 필요없는 clock등을 끄거나 frequency를 낮춘 상태로 대기하고 있는 상태입니다. Standby mode는 영어 본래의 뜻과는 좀 다른 상태로 있게 됩니다. 원래 standby는 준비 완료 상태를 의미하는 것인데, HDD 상에서 보면 이건 뭐 거의 죽어 있는 것이나 다름 없습니다. Head는 disk 위에 있지 않고 ramp에 나가있거나 parking zone 위에 올라가 있으며, spindle motor도 동작하지 않습니다. Clock이 살아 있는 것을 제외하고는 거의 power off 상태와 별반 다름이 없습니다. HDD에서 spindle motor가 전력 소모가 가장 많은 부분이니 PM 측면에서 보자면 거의 전력을 소모하지 않습니다. 그러면 어떤 단점이 있을까요? 통상적으로 PC에서 HDD의 ready 시간 제한을 8초 정도로 두는데, 깨어날 때 이 정도는 아니어도 꽤 많은 시간을 잡아 먹습니다. 즉 전력 소모를 줄이겠다고 수시로 standby mode로 진입시키고 또 깨어나게 하고 하면 성능에 막대한 영향을 끼치게 됩니다. 제가 경험한 embedded system에서는 전력 소모를 줄이기 위해서 갖가지 기능을 활용하면 할 수록 성능은 반비례하였습니다. 적당한 타협선이 필요한데 이 놈의 OEM들은 전력 소모도 줄여달라 성능도 높여달라고 하니 가끔은 짜증이 만발할 때도 있습니다. Sleep mode는 standby mode에서 더 많은 clock 등을 끄거나 낮춥니다. 진짜 죽은 것이나 다름 없을 정도이지요. 그럼 standby와는 어떤 차이가 있을까요? Standby mode에서는 어떤 command 든지 받을 수가 있습니다. 전력 소모는 최소로 하되 command를 받고 동작을 수행하는데 있어서 준비 상태로 있는 것입니다. 그러나 sleep mode에서는 단 한가지 command를 제외하고는 다 거부하도록 되어 있습니다. 그 한 가지 command는 바로 RESET command입니다. Sleep mode에 있다가 RESET command를 받으면 어떻게 될까요? 바로 standby mode로 진입하게 됩니다. ATA에는 state diagram이 몇개 있는데 위에서 제가 말한 내용을 이 것으로 표현하자면 아래와 같습니다.

[그림 2. Power Management State Diagram]

 뭔가 복잡한가요? 뭐 별로 복잡할 건 없습니다. 그냥 command 받으면 그 상태로 진입한다는 것과 sleep mode에서 다른 mode로의 천이는 반드시 reset이 필요하다는 것 밖에 없습니다.

 위에서 설명한 내용은 각 단계로 진입하는 부분에 대해서만 말한 것으로, 놀고 있는 mode에서 active mode로 천이할 때 한 가지 특별한 규칙이 있습니다. 그건 바로 실제 R/W access가 이루어 지지 않을 때는 굳이 놀고 있는 mode에서 active mode로 천이할 필요가 없다는 것입니다. 그럼 어떻게 access가 이루어지는지를 판단할까요? 그건 바로 앞 글에서 설명드린 data command와 non-data command인지를 가지고 판별합니다. Non-data command일 경우 access를 할 필요가 없으므로 굳이 active mode로 갈 필요가 없습니다. 또한 data command라 할지라도 cache command의 경우 hit 되었을 때는 굳이 access를 할 필요가 없으니 이 때도 active mode로 가지 않아도 됩니다. 가끔 제대로된 state diagram을 보면 설계자의 연륜과 그 완벽함에 감탄이 절로 나올  때가 있는데 ATA의 PM도 마찬가지인 것 같습니다. Access 여부에 따라 천이 여부를 결정하니깐요.

 오늘은 여기까지만 하겠습니다.... 라고 끝맺을려고 하다 보니 APM에 관련된 내용이 빠져있군요. 아놔~ APM은 업무상 비밀을 포함하고 있는 내용이 많으니 자세하게 설명하기 어렵겠네요...란 말로 회피하고 싶습니다. 아하하... 사실 별다른 것이 없습니다. 말 그대로 PM에 advanced한 기능을 집어 넣은 것 빼고는 말이죠. 이 것이 왜 들어갔는지를 생각해보니, PM에서 말하는 PM status는 active/idle/standby/sleep mode 네 가지가 있는데, 전력 소모를 줄이기 위해 뭔가를 더 세분화할 필요가 있었던 것입니다. 왜냐고요? Active와 standby와의 차이가 너무 심했던 겁니다. 무엇을 쪼갤까 고민하던 선배 engineer들께서는 한참을 고민하던 중 idle이 제일 만만하구나라고 생각하셨던 것입니다. 그래서 '야 제조사, 너네들 idle을 더 세분화켜서 전력 소모를 줄일 수 있는 방법을 연구해봐'가 되었고, 결국 idle에서 또 몇 단계로 나누어지게 됩니다. 그런데, 이건 spec.에서 따로 명시하지 않았기에 제조사별로 각기 다른 이름을 가지고 있는 듯 합니다. 현재 spec에 나뉘어진 이 세분화 단계는 01h ~ FEh까지 254 단계나 됩니다. 이 level은 SET FEATURE command로 제어를 할 수가 있습니다. 또한 SET FEATURE command로 APM을 enable/disable을 할 수 있으니, host system에 맞게 편한대로 사용할 수 있도록 만들어져 있습니다. 

 진짜 마지막이었습니다.

 다음 번엔 몇가지 feature set에 대해 더 살표보도록 하겠습니다.

뱀 뒷다리,

  한 동안 업무에 치여서 이런 글을 쓰고 있었다는 것도 까먹고 있었는데, 오늘 댓글을 보고 의욕을 살려 다시 쓰게 되었습니다.

from http://sutdaeng.egloos.com/3282269

ATA 이야기2

저번 시간에는 ATA device들과의 통신에 있어서 가장 기본이 되는 TFR(Task File Register)과 그 구성 원리에 대해 이야기했습니다. 이번에는 ATA 장치가 동작하는데 있어서 필요한 command들에 대해 각각의 특징별로 구분하는 Feature Set이라는 것에 대해서 알아보겠습니다. Feature set은 PACKET device냐 아니냐에 따라 조금 다르긴 하지만, 전 PACKET device는 다루지 않으니 본 글에서는 제외하도록 하겠습니다.
 첫 번째로 살펴볼 것은 general feature set입니다. 말 그대로 가장 일반적인 feature들입니다. ATA device는 저장 장치라고 전 글에서 언급한 적이 있듯이, 저장 장치에 일반적으로 필요한 기능이 뭐겠습니까? 바로 read/write 아니겠습니까? 그래서 general feature set을 이루는 command는 대부분 R/W에 관련된 것들입니다. 아래는 non-PACKET device의 경우 반드시 구현되어져야만 하는 command들입니다.
  - EXECUTE DEVICE DIAGNOSTIC
  - FLUSH CACHE
  - IDENTIFY DEVICE
  - READ DMA
  - READ MULTIPLE
  - READ SECTOR
  - READ VERIFY SECTOR
  - SET FEATURES
  - SET MULTIPLE MODE
  - WRITE DMA
  - WRITE MULTIPLE
  - WRITE SECTOR
 딱 보면 알 수 있듯이 R/W에 관련된 command가 대부분을 이룹니다. 하나 씩 대충대충만 살펴보도록 하겠습니다.
 EXECUTE DEVICE DIAGNOSTIC command는 device에게 알아서 자가 진단을 해보고 결과를 알려달라는 것입니다. 여기서 ATA spec.의 가장 큰 단점이라면 단점이라 할 수 있는 무책임성을 하나 발견할 수 있습니다. 그게 뭐냐면, 자가 진단을 수행하라는 내용만 있지 구체적으로 어떤 진단을 하라는 것인지에 대한 세부 내용은 없습니다. 즉 제조사 마음대로 command를 받고 자가 진단을 수행했다는 결과만 알려주면 되는 것입니다. 비밀을 알려드리자면 현재는 거의 무용지물에 가까운 녀석입니다. 그 이유는 대부분 power-on을 할 때 내부 진단을 수행하기 때문에 이 command를 받을 쯤이면 해당 동작은 거의 수행된 것이나 마찬가지이기에 현재는 이 command를 받고 별다른 동작을 수행하지 않는 것이 관례가 돼버렸습니다.
 FLUSH CACHE command는 굉장히 낯익지 않나요? 네 맞습니다. 장치의 내부 cache를 비워야 할 때 씁니다. 그러데 단순히 비우는 것만은 아닙니다. 이 flush라는 동작이 어떻게 동작하고 또 실제 어떤 의미를 지니는지에 대해서는 다음에 다루도록 하겠습니다.
 IDENTIFY DEVICE는 뭘까요? 영문 그대로 하면 '니 정체를 밝혀라!" 정도 되는데 굉장히 중요한 command 입니다. 여러분의 OS에서 장치관리자를 보면 각 장치에 대한 여러가지 정보를 볼 수 있죠? 그걸 어떻게 가져올까요? 바로 이 command를 써서 data를 가져오는 것입니다. 단일 command에서 다루는 내용으로 치자면 가장 방대하다할 만큼 양이 많으니 나중에 이 녀석을 다룰 때 다시 상세하게 쓰도록 하겠습니다. 제 생각이지만 이 command에서 다루는 data만 제대로 이해해도 ATA를 거의 이해한 거나 다름 없다고 봅니다.
 나머지 R/W 애들은 data 전송 방식의 차이만 있을 뿐 실제는 모두 장치와의 data I/O를 위한 것입니다. 이 중에 MULTIPLE 계열은 좀 독특한 방식을 씁니다. 다른 R/W command들은 sector count값에 따라 I/O의 단위를 결정하는데, 이 녀석들은 sector count * multiple sector size로 결정하게 됩니다. 무슨 의미냐면 SET MULTIPLE command로 multiple sector size를 16 sector로 주고 나서 READ MULTIPLE command로 sector count를 2를 주면 실제 read data는 2 sector가 아니라 2*16 = 32sector가 된다는 것입니다. 참 재미있는 녀석들이죠?
 마지막으로 SET FEATURE command는 전편의 글에서도 살짝 다룬 적이 있었는데, 장치들의 어떤 내부 동작에 관련된 내용들을 사용자 입맛에 맞게 변경하고자 할 때 사용합니다. 이 녀석도 양이 만만치 않으니 나중에 좀더 자세히 다루도록 하겠습니다.
 읽기만 가능한 장치들은 위에서 FLUSH CACHE와 write 계열 command만 빼고 구현하면 되는 것입니다. 위의 command set은 반드시 구현되어야만 하는 것들입니다. ATA spec.에서 중요하게 보셔야 할 단어가 두 개가 있습니다. 바로 'mandatory'와 'optional'인데 전자는 반드시 구현되어야만 하는 것들에 대한 것들이고 후자는 장치 제조업체 마음에 달려있습니다. 그러나 아쉽게도 OEM들은 spec.에 나와 있는 모든 것들이 구현되기를 바라니 사실상 'optional'은 의미가 없습니다. 전부 'mandatory'입니다.
 Non-PACKET 장치들과 PACKET 장치들의 general feature set을 위한 command 중에 아주 독특한 녀석이 한 개 있습니다. DEVICE RESET이라는 command입니다. PACKET 장치들은 위의 command를 장치의 초기화를 위하여 사용합니다만, non-PACKET 장치들은 초기화 단계가 세 개로 나누어져 있어 위 command를 지원하지 않습니다. 앞에서 살짝 언급했었는데, 후자의 장치들은 reset이 세 가지 종류가 있습니다. Power-on reset, hardware reset 그리고 software reset 등이 바로 그 것입니다. 각각을 설명하자면 이렇습니다.
 Power-on reset은 말 그대로 전원이 인가되고 나서 장치가 내부 동작을 수행한 다음 command 수행을 위한 만반의 준비가 되면 host에게 '나 준비 됐어~'라고 알려주는 TFR set을 보내줍니다. 이 모든 단계를 통틀어서 power-on reset이라고 합니다. TFR set을 언급했는데 power-on reset에 대한 응답은 특수한 값을 실어서 보내도록 규정되어 있습니다. 간단합니다. Status : 0x50, Error : 0x01, Sector : 0x01, Sector count : 0x01 등의 정보를 담아서 보내주면 됩니다. 제가 전편의 글에서 command를 보내면 항상 그에 대한 응답을 보내야만 한다고 했었죠? Host가 command를 보내지 않았는데 장치가 먼저 응답을 보내는 경우는 위의 경우 단 한 가지 뿐입니다. 가끔 장치들이 원인 모를 상태에 빠졌을 때 debugging을 위하여 TFR 값을 읽어봤더니 위와 같으면 그건 무조건 power-on reset이 걸린 상태고 이는 전압/전력 부족으로 인하여 장치가 알아서 꺼졌다 켜진 것을 의미하는 것으로 이해하시면 됩니다. 최근 저전력 장치들에 대한 수요가 높아져서 인지 이런 경우가 많이 발생하는 것 같으니 참고하시면 되겠습니다.
 Soft reset은 앞에서 살펴본 것들 중에 Device Control register에 SRST bit을 키고 보내면 동작하고, 이에 대한 응답은 power-on reset에 대한 TFR set 값과 동일합니다.
 Hardware reset은 interface 방식에 따라 조금 다르지만, PATA에서는 RESET- signal을 SATA에서는 COMRESET signal을 사용한다는 것 외에는 동일한 의미이고, TFR set도 위와 동일합니다.
 그럼 장치 내부적으로 soft와 hard의 차이는 무엇일까요? 각각의 동작을 위한 구성은 조금 복잡합니다만, 전자는 hardware block까지는 초기화시키지 않고, 후자는 hardware block까지 초기화를 진행시킨다는 차이가 가장 큽니다. 특히나 후자의 경우에는 interface block에 대하여 power-on reset과 거의 비슷한 수준까지 초기화를 진행합니다. 그런데 사실 이건 spec.에서도 명시적으로 기술해놓지 않았기 때문에 제조사의 마음에 달린 문제입니다. ATA spec.이 뭉뚱그려서 추상적인 개념만 잡아 놓고 세부 구체적인 내용에 대해서는 전부 제조사의 몫으로 떠넘겨버리는 내용이 많아서, 자의적인 해석이 얼마든지 가능합니다. 그래서 무식하고 잘 모르는 OEM과 spec. 관련 회의를 할 때면 한 대 때려주고 싶은 마음이 간절할 때가 많습니다. 자기들 멋대로 해석해서 구현해달라고 우기는 경우가 정말 많더군요.
 이상 General feature set에 대해 이야기해보았습니다. 원래 계획은 한 개 더 쓰는 거였는데, power management 쪽은 다음 글에 쓰도록 하겠습니다.

수정)

READ MULTIPLE command의 경우 전송되는 총 sector의 개수가 SET MULTIPLE에 의해 늘어나는 것이 아니라
sector count만큼의 data가 SET MULTIPLE로 지정된 DRQ data block size로 나뉘어 전송되는 것입니다.

예를 들어 DRQ data block size가 4로 지정되어 있을때
READ SECTOR command로 count field에 7을 지정하면 7개 sector가 7개 DRQ data block으로 전송되고,
READ MULTIPLE command로 count field에 7을 지정하면 7개 sector가 3개 DRQ data block로 전송됩니다 (각 4sectors, 4sectors, 1sector 크기).

쓰이는 command도 아니지만... 많은 도움 얻은 글에 아쉬운 점이 있어서 댓글 남겨둡니다.
언젠가 ATA 이야기 - 7도 올라오길 기대할게요 ^^

from blog
http://sutdaeng.egloos.com/3035261

ATA 이야기1

ATA와 ATAPI라는 말을 혹시 들어본 적이 있습니까? 꼭 "도를 아십니까?"라는 말과 비슷한 느낌을 풍기는 군요...
 대학교를 9년이나 다녔고 자칭 뼛속 깊은 공대생에 programming을 공부하며 지낸 저도, 입사하고 처음 들어본 말이었습니다. ATA spec.은 양도 꽤 많고 전부 영어로 되어 있어, 입사하고 한참을 ATA spec. 문서를 읽고 또 읽으며 이해하려 노력해야 했었습니다. 지금이야 이렇게 ATA에 관련된 내용의 글을 쓸 수 있게 되었지만, 그 때는 정말 마법의 언어였었습니다.
 처음 질문으로 돌아가서, ATA라는 것은 Advanced Technology Atatchment의 약자로 저장 장치와의 통신을 위하여, 주요 HDD 제조 업체 및 표준제정 집단에서 만들어진 일종의 protocol 문서입니다. 제가 생각하는 spec 탄생에 대한 대강의 역사는 흔히 computer라 불리는 기기에 쓰이는 보조 기억 장치 기기들이 여러 종류 등장하게 되고, 각종 저장 장치들과의 통신하는 방법이 각양각색이라 이를 통합 및 표준화하고자 만들어진 것이 ATA spec의 시초일 것 같습니다. 현재 남아있고 또 쉽게 찾아볼 수 있는 ATA 장치라고 하면 HDD, SSD, CD-ROM 장치 정도가 되겠습니다. ATA에서는 저장 장치류를 구분할 때 removable과 그렇지 않은 녀석으로 구분합니다.위의 세 가지는 non-removable이고 removable의 대표적인 예는 USB 장치가 있습니다. 그렇습니다. ATA 장치라 함은 곧 저장 장치를 뜻하는 것으로 이해하면 될 것 같습니다.
 그럼 ATAPI는 무엇일까요? ATA with Packet Interface 장치를 말합니다. CD-ROM 장치나 SCSI 장치 등Packet Interface를 사용하는 장치들의 지원을 위해 추가된 내용을 말합니다.  ATA에서 저장 장치와 통신하는 interface 방식은 PATA와 SATA 두 가지 방식이 있습니다.
 PATA는 전송 속도의 한계가 존재하기에, 현재 고용량화되어 전송 속도가 한계치를 넘어버린 2.5" HDD 이상에서는 거의 쓰이지 않습니다. 아주 드문 경우로 전력 소모가 굉장히 중요한 요소가 되는 장치에서는 가끔 쓰이는 경우가 있고, 전송 속도가 중요하지 않는 소형 HDD에도 사용되고 있긴 하나 이젠 구시대의 유물로 처리되는 분위기입니다. 중요한 걸 빠트렸군요. PATA는 Parallel ATA의 약자로 병렬 방식으로 통신하는 것을 뜻합니다.
 SATA는 Serial ATA로 직렬 방식의 interface로 PATA의 전송 속도 한계를 극복하고자 만들어진 것입니다. 물론 전송 속도 외에 SATA 만이 가지는 고유한 명령어나 power management를 위한 몇 가지 방식이 도입되기는 했으나, 일반인이 이해하기에 PATA와의 차이점은 통신 방식과 전송 속도의 차이면 충분할 것 같습니다. SATA가 대세가 되어버린 지금, 기술도 많이 발전하여 어느새 3.0까지 나왔습니다. 각각의 version 별로 조금씩 추가되고 발전된 내용이 있긴 하지만 간단하게 말하자면, 1.0은 1.5Gb/s, 2.0은 3.0Gb/s, 3.0은 6.0Gb/s 이런식으로 지원하는 전송 속도가 뒤로 갈 수록 빨라지게 됩니다. SATA는 별도의 spec이 존재할만큼 그 내용이 방대하기에 나중에 따로 다루도록 하겠습니다.
 이 글에서 뿐만 아니라 앞으로 이어질 글에서도, 자료형의 정의는 아래와 같습니다. 보통 word라는 녀석은 chip에 많이 의존하는데 spec이 만들어졌을 때 16bit chip을 썼나 봅니다. 그리고 아직도 16bit입니다.
  - Byte : 8bit
  - WORD : 16bit = 2 bytes
  - DWORD : 16bit = 2 words = 4 bytes

 ATA spec의 주 내용 중 거의 70%는 command에 관련된 내용이니, command가 어떻게 나가고 그에 대한 응답을 어떻게 받는지를 먼저 알 필요가 있겠습니다. ATA에서 I/O의 가장 기본이 되는 것은 바로 Task File Register(이하 TFR) 입니다. TFR의 구성은 command의 종류에 따라 다지만 기본 구성은 아래와 같습니다.
원래는 TFR이라는 용어가 없는데, 제가 Task File Register를 계속 쓰려하니 귀찮아서 만든 약어입니다. 전체적인 TFR set의 구성은 아래 그림과 같습니다.

 28bit command의 경우 1 byte 크기를 가지는 7개의 register를 사용하고, 48 bit의 경우 2 byte 크기를 가지는 register 5개와 1 byte 크기를 가지는 register 2개를 사용합니다. 뭐 결국 크기만 다르지 TFR의 개수는 동일하다고 보면 됩니다. 아래 그림은 각각의 경우에 대한 TFR이 어떻게 구성되는지에 대한 것입니다.
 

[28bit Read DMA command에 대한 TFR 구성] 

[48bit Read DMA Extended command에 대한 TFR 구성]

 맨 처음 그림(I/O registers)에 보이는 것과 실제 command를 보낼 때의 사용을 보면 한 녀석이 비는 것을 찾으셨나요? 빠진 녀석은 Data register인데 이는 DATA I/O coomand에서 실제 어떤 data를 I/O할 것인지에 대한 정보를 담고 있는 녀석입니다. Non-data command에서는 이 녀석을 사용하지 않습니다.
 그럼 28bit command와 48bit command는 무엇일까요? 초기에 저장 장치는 용량이 작아서 28bit면 모든 영역에 대하여 주소 지정을 할 수가 있었습니다. 28bit면 128GB까지 주소 지정을 할 수가 있습니다. 그러다 몇 년 전부터 128GB를 넘는 HDD가 쏟아져 나오기 시작하면서부터 28bit command로는 128GB를 넘는 영역에 대하여 access를 할 수 없게 됩니다. 이 문제를 해결하기 위하여 48bit command가 만들어졌고 이들을 위한 TFR set이 추가되게 됩니다. 간단하게 48bit command는 128GB보다 더 큰 용량을 가지는 저장 장치를 처리하기 위한 command인 것입니다. 48bit를 가지고 처리할 수 있는 용량은 128PB 까지입니다. 감이 안오시나요? 128PB = 131072TB = 134217728GB가 됩니다. 현재 2TB의 3.5" HDD가 막 개발되어 양산 준비 중인 것을 보면 한동안은 48bit로도 충분할 것으로 보입니다. 여기서 예리하신 분은 어떻게 위의 용량이 나오게 됐는지 궁금하실 겁니다. 28bit를 가지고 계산하면 256M까지 밖에 나오지 않는데 어떻게 128GB가 되는 것일까요? 그 이유는 각각의 bit는 각각의 sector를 가르키기 때문입니다. 그럼 sector는 뭘까요? sector라는 것은 HDD에 access할 때 최소 단위이고 그 크기는 현재 일반적인 기준으로 512bytes입니다. 즉 256M * 512bytes = 128GB가 되는 것입니다. 잠시 딴 이야기를 해보자면 과거 1 sector = 512 bytes라는 인식이 지배적이었습니다. 그러나 HDD도 용량 늘리기의 한계에 부딛혔는지 sector 크기를 늘리기 시작하고 있습니다. 실제로 Western Digital의 경우 sector 크기를 늘린 새로운 sector 크기에 대하여 뭔가 신기술인 마냥 언론에 홍보를 시작하더군요. 왜 sector 크기를 늘리면 용량 확보에 유리한지에 대한 이유는 시간이 되면 설명드리고 일단은 현 추세가 그렇다는 것입니다. 이렇게 sector 크기를 늘린 것에 대해 super sector 또는 multi-sector라는 용어를 사용하고 있습니다. 그러나 문제는 이렇게 sector 크기를 늘리더라도 Windows XP에서는 해당 HDD를 사용할 수 없습니다. OS에서 지원하지 않기 때문이죠. Vista 이상의 상위 version에서는 지원하도록 돼있습니다. Linux 계열은 잘 모르겠네요...
 TFR을 설명하다가 얘기가 잠시 딴 곳으로 새버렸군요. 다시 본론으로 돌아와서, TFR이 28bit와 48bit 두 종류로 이루어져있지만 주소를 지정하는 부분을 제외하고는 실제 command code와 sub-command를 처리하기 위한 feature code의 사용은 거의 동일하기에, 두 경우에 대해 공통적으로 적용되는 각각의 녀석들에 대해 알아보도록 하겠습니다. TFR은 Host to Device(이하 H2D)로의 방향과 Device to Host(D2H)로의 방향에 따라 각각의 녀석들이 다른 의미로 사용됩니다. 일단은 H2D 방향에서 어떻게 사용되고 그 의미가 무엇인지에 대해 알아보겠습니다. 위의 그림들은 모두 H2D 방향입니다. H2D 방향에서 가장 중요한 녀석은 command register 입니다. Command는 host가 device로 어떤 command를 보낼 것인가에 대한 정보를 담고 있습니다. ATA spec.에 나와있는 command는 많이 있으나 그 종류는 딱 세 가지 밖에 없습니다. 더 크게 나누자면 두 종류입니다. data I/O가 있는 command와 없는 command로 일단 나뉘고, I/O의 방향에 따라 DATA in/out으로 나뉘게 됩니다. 여기서 in/out의 방향을 제대로 이해하셔야 합니다. 기준은 host를 말하기 때문에 in이라는 것은 host로 data가 들어오는 것을 의미합니다. Host로 data가 들어온다 즉, 저장 장치로부터 data를 읽으면 그 data가 들어오기 때문에 붙여진 이름입니다. Read 계열의 command가 data in command 입니다. Out은 반대로 write 계열입니다. 물론 모든 command에 대해 read/write로 분류할 수는 없지만 여기서는 in/out의 개념을 설명하고자 한 것입니다. 요약하자면 command register는 어떤 command를 보낼지에 대한 값이고 그 값은 spec.에 정해져 있고, 그 종류는 DATA IN, DATA OUT 그리고 NON-DATA command로 분류할 수 있다입니다.
 Feature register는 위에서 살짝 언급했지만 sub-command를 사용하고 싶을 때 사용합니다. Read나 Write command의 경우 단순하게 data I/O 밖에 없는 경우는 feature register를 사용하지 않습니다. 반대로 ATA command 중에 SET FEATURE라는 녀석이 있는데 이 녀석은 HDD의 여러가지 feature들을 사용자 입맛에 맞게 제어할 수 있도록 해줍니다. 그런데 feature들이 워낙 많으니 각각의 feature들을 제어하기 위하여 각각에 대하여 sub-command code를 할당해놓았습니다. 그래서 host가 command를 실어 보낼 때 특정 feature를 선택하고 싶을 때 각 feature에 해당하는 값을 feature register에 함께 싫어서 보내게 되면, 저장 장치는 이 것에 맞게 해당 feature를 제어하는 것입니다.
 Device register는 말 그대로입니다.
오래전에는 주소 지정 방식이 HDD에서 사용하는 cylinder, head, sector(이하 CHS)와 같은 physical address를 직접 지정해서 access할 수 있는 방식을 사용하던 때가 있었다고 합니다. 그러다 CHS 방식이 위에서 언급한 용량의 한계와 비슷한 문제에 부딛혀서 이를 극복하고자 Logical Block Address(이하 LBA) 방식이 도입되게 됩니다. 이렇다 보니 CHS command와 LBA command를 구분하기 위한 방법이 필요했고 이를 위하여 device register에 bit 하나를 할당해줍니다. 또 예전의 PATA interface 시절에 여러개의 HDD를 사용하고 싶을 때 각각을 구분하기 위해 master/slave라는 개념을 사용했었습니다. 이를 구분하기 위해 또 bit를 할당해주었습니다. 이 외에 feature register 처럼 각각의 command에서 제어하고자 하는 기능들이 다르기 때문에 각 command마다 각자 입맛에 맞게 이를 사용하기도 합니다. 각각의 bit definition은 아래와 같습니다.

 다음은 sector count register입니다. 이름에서 벌써 팍 꽂히지 않습니까? 맞습니다. DATA I/O 계열의 command에서는 얼마나 I/O를 할 것인지에 대한 정보를 담고 있는 녀석입니다. 28bit command에서는 8bits를 사용하기에 최대 I/O size는 255 sectors가 되고, 48bit command는 16bits를 사용하기에 65535 sectors가 최대가 됩니다. 48bit command의 경우 I/O size가 크니 28bit command에 비해 command를 더 적게 사용해도 되는 장점이 있습니다. 하지만 제가 아는바로는 XP는 127 sectors 이상을 사용하지 않습니다. 공전절후의 hit를 기록한 OS XP도 시간이 지나니 점점 퇴물이 되는 것은 어쩔 수 없나 봅니다. NON-DATA command 계열에서는 또 다르게 사용되기도 합니다. Feature/Device register처럼 해당 command에 대하여 sub-control이 필요할 때 사용하기도 합니다. Sub-control/command에 관련된 내용은 각각의 command를 살펴볼 때 어떤 의미와 어떻게 사용되는지 알아보도록 하겠고, 여기서는 간단하게 넘기도록 하겠습니다.
 자 마지막으로 주소 지정 register들입니다. 이 녀석들은 정말 딱 한 개를 제외하고는 NON-DATA command에서는 거의 의미가 없는 녀석들입니다. 좀더 진실을 말하자면 ATA spec.에 있는 command에 대해서지만요. 그리고 위의 그 한 개라는 주인공은 SMART command인데 이 녀석의 복잡도는 ATA command 중 최강을 달리기 때문에 나중에 설명하도록 하겠습니다. 아무튼 주소 지정 register는 DATA IN/OUT command에서 저장 장치의 특정 위치를 access하고자 할 때 그 주소를 지정해주는데 사용합니다. 28bit command는 8bits로 이루어진 register 3개, LBA Low, LBA Mid, LBA High와 device register의 하위 4bit를 빌려서 주소를 지정하게 됩니다. 위의 READ DMA command에 대한 TFR 그림을 보시면 어떻게 구성되는지를 보여줍니다. 48bit는 16bits로 이루어진 LBA L/M/H를 사용하고 따로 빌려쓰지는 않습니다. 그런데 한 가지 좀 복잡한 것이 있다면 순차적으로 L/M/H를 붙이면 LBA가 나오는 것이 아니라 좀 뒤 엉켜 있는 것을 알 수 있습니다. 그 이유는 기존의 28bit 시절에 TFR 뒤에 48bit를 위한 TFR을 추가한 꼴이 되버렸기 때문입니다. TFR은 순차적으로 위치해있는데 그 순서를 뒤바꾸면 호환성에 문제가 생기니 뒤에 추가하게 된 것이고, 그렇다 보니 이렇게 엉망이 되버린 것입니다. 그러나 위의 LBA 계산은 모두 I/O controller chip이 알아서 해주니, 직접 register들을 열어보지 않는 이상 계산상의 수고스러움은 없을 것입니다. 전 직접 열어볼 일이 많기 때문에 애시당초 잘 만들지라는 생각을 매번 하게 되고, 계산할 때마다 짜증이 묻어납니다...
 마지막으로 Device Control register 입니다. Bit 중에 bit 7은 HOB(High Order Byte)로 H2D로는 48 bit/28 bit command에 대한 정보를 알려주는 기능과, bit 2의 SRST는 soft reset에 대한 처리를 위한 기능 그리고 data 전송 제어를 위한 위한 bit 1, nIEN bit 세 가지가 중요하게 쓰입니다. 첫 번째를 빼고는 다소 어렵고 복잡한 내용입니다. 간단하게 얘기를 하자면 RESET coomand를 보낼 때 SRST bit을 set 해서 command를 보내고, nIEN은 device로부터의 INTRQ를 enable하느냐 disable하느냐를 제어하기 위한 bit 입니다. 이건 간단하게 얘기해도 복잡하네요... 써놓고 보니 HOB와 SRST는 이해가 되는군요. nIEN은 아직은 4차원인 것 같으니 차후 SATA protocol을 다룰 때 설명하도록 하겠습니다.
 자, 이제까지 H2D로의 TFR의 의미와 어떻게 쓰이는지 알아봤으니 D2H에 대한 것도 알아보겠습니다.
 D2H로의 TFR은 굉장히 간단하면서도 알아야 할 것들이 좀 있습니다. 간단한 것만 여기서 다루고 알아야 할 것들은 각각의 command를 다루는 부분에서 설명하도록 하겠습니다. 그럼 간단한 것에 대해 알아보죠. 왜 간단하다는 표현을 썼냐면, 기본 적인 틀은 모든 command가 비슷하기 때문입니다. command를 보내는 것이 H2D니 거기에 대한 응답이 D2H가 되고, 이 때 담을 내용은 command를 수행했는데 결과가 어떻더라는 것이 전부입니다. 더 간단하게 말하면 error가 있었냐 없었냐만 알려주면 되는 것이죠. 그래서 D2H TFR set은 항상 status와 error register 값을 유심히 살펴볼 필요가 있습니다.
 먼저 status register는 error가 있었냐 없었냐에 대한 정보와 현재 장치의 상태가 어떠한가에 대한 정보를 담아서 보내주는 녀석입니다. 각각의 bit definition은 아래 그림과 같습니다.

[Status Register의 bit definition]
 그럼 각각의 bit에 대한 의미를 살펴보겠습니다. BSY bit은 현재 장치가 동작 중이라는 뜻으로 busy의 약자입니다. 장치가 해당 command를 수행하기 위해 열심히 뭔가를  하고 있다는 것을 뜻합니다. DRDY는 drive ready의 약자로 말 그대로 새로운 command를 수행할 준비가 되어 있다는 뜻입니다. DF/SE는 각각 device fault/stream error를 뜻하는 것으로, 모든 command에서 set 해서 내보내지는 않습니다. 약 3년 간 HDD를 지켜보고 있지만 단 한 번도 보지 못한 bit 입니다. 잘 안쓰이는 것 같더군요. SE는 streaming command만 set 하는 bit입니다. 이 녀석에 대한 것은 feature set을 다룰 때 살펴보도록 하겠습니다. Bit 4는 저장장치의 종류에 따라 다르게 쓰입니다. 가령 HDD의 경우 seek라는 동작을 매 read/write 마다 수행하기에 일반적으로 DRDY에 bit 4를 함께 set 합니다. 보통 DSC로 불리며무슨 의미냐면, Device Seek Complete를 뜻합니다. 이상 상위 bit 4개에 대해 살펴보았습니다. 한 숨 돌리고 하위 4bit를 살펴보겠습니다. 하악하악(^.^;;;)
 하위 4bit 중 bit 1, 2는 현재 제가 이 글을 쓰고 있는 ATA-7 기준으로는 사용되지 않습니다. 설명할게 줄어서 정말 기쁩니다~. 이번엔 순서를 바꿔서 bit 0부터 설명하겠습니다. 사실 bit 0는 command에 대한 응답으로써의 TFR 중 error가 있었냐 없었냐를 알려주는 매우 중요한 bit입니다. 명칭은 ERR/CHK 이고 Error/Check 입니다. 즉 error가 났으니 error register를 check 해보라 라는 뜻입니다. Bit 3인 DRQ는 Data ReQuest를 뜻합니다. 이것도 각각의 data 전송 방식에 따라 set 되는 위치가 바뀌기는 하지만 기본적인 의미는 data 전송 중이라는 의미입니다. 자 그럼 이렇게도 생각을 해볼까요? Device가 data를 전송 중이라면 바쁜 상황일까요? 아닐까요? 네 당연 바쁜 상황이겠죠. 그래서 보통 DRQ는 BSY bit랑 거의 대부분 함께 짝을 이룹니다. 각각의 protocol 아주 미묘한 시간차에 의해 아닐 때가 있긴 하지만 우리는 인간이니깐 ns(nano second) 차원은 무시해버립시다. 가끔 이런 ns 차원도 다뤄야하기 때문에 interface debugging은 어려울 때가 있습니다. 이상으로 status register의 bit definition을 살펴보았습니다. 이 녀석은 모든 command에 대해 그 응답이 어떠한 가를 나타내는 정보를 담고 있기 때문에 항상 살펴보아야 하고 값에 대해 관심을 가져야 하는 아주 중요한 녀석입니다. 위에서 H2D로의 TFR을 설명하면서 Device Control register를 설명했었습니다. 이게 H2D에서는 Device Control register지만 D2H에서는 Alternate Status register로 사용됩니다. 말 그대로 status register의 복사판이 되겠습니다.
 후아~ 드디어 마지막인 error register 군요. Error register는 각 command가 가지는 동작 특성이 다르기 때문에 각 command에 대해서 bit definition을 다르게 사용합니다. 모든 command에 대해 동일하게 사용하는 녀석이 있긴 합니다. 아래 그림을 보시죠.

  그렇습니다. Bit 2는 ABRT, 즉 abort로써 어떤 command를 보냈을 때 저장 장치가 지원하지 않거나, 조건이 만족하지 않았을 때 거부할 때 쓰이는 bit입니다. 참 건방진 녀석이죠. 전지전능하신 host님께서 command를 보냈는데 일개 주변 장치 따위인 device가 거부하다니요. 아주 간단하게 이런 경우를 가지고 설명을 할 수가 있겠습니다. Packet device와 non-packet device는 각각이 지원하는 command가 다릅니다. Host가 Packet device에 날려야 할 command를 non-packet device에 날린다면, 당연 수행할 수가 없겠죠? 이렇게 각각의 저장 장치에서 지원하지 않는 command가 들어올 때 과감히 abort error를 내는 것입니다. 그럼 이런 경우만 있느냐? 그러면 정말 ATA spec. 쉬워졌을 것입니다. 아쉽게도 state transition을 가지는 command들은 모두 해당 조건을 만족하지 않은 경우에 과감하게 거부해버립니다. State transition을 가지는 feature set과 command의 종류는 다음에 자세히 다루도록 하겠습니다. 더불어 각각의 error bit은 command마다 다르니 command를 다룰 때 이 녀석들을 설명드리도록 하겠습니다. 아... 이건 제가 귀찮아서 그러는 것이 아니라, spec.에서 command에 대해 설명할 때 일반적인 input으로써의 TFR set과 output으로써의 TFR set, 그리고 error가 발생했을 때의 output으로써의 TFR set을 다루기 때문입니다. 무엇보다 너무 글을 길게 썼더니 슬슬 지쳐가기 시작하네요...
 후아.. 이렇게 길게 글을 써본 적이 과연 몇번이나 되는지 모르겠군요. 제가 생각하는 ATA spec.을 이해하는데 있어서 가장 기본이 되는 TFR set에 대한 내용과 이들이 어떻게 사용되는지에 대한 주제로 일반인이 보기에 쉽게 이해할 수 있도록 글을 쓰고자 노력하였습니다. 어떻게 좀 이해가 되시나요? 이 다음글에서는 ATA spec.에서 각각의 특징별로 구분해 놓은 것이 있는데 이를 feature set이라고 하고 이에 대해서 다루고자 합니다.

뒷 이야기,
 1. Mb/s와 MB/s의 차이를 아시나요? MB/s = (Mb/s)/8 입니다. 위의 1.5Gb/s는 overhead를 제외한 순수 전송 속도를 계산하면 192MB/s 입니다.
 2. 예전에 PATA와 SATA 중 뭐가 더 좋은가라는 질문을 받은 적이 있는데, 비교 불가입니다. 무조건 SATA입니다. 전송 속도 차이도 있지만, PATA를 사용하는 저장장치와 SATA를 사용하는 것의 세대 차이는 기술적 의미로 거의 3세대 이상 차이가 나기 때문입니다.
 3. ATA 이야기가 끝나면 SATA 이야기란 내용으로 글을 이어 갈까 합니다.




from http://sutdaeng.egloos.com/2831491

Sutdaeng

하드디스크를 위한 고속 인터페이스 - SATA(Serial ATA)

PC의 구성품 중 중요한 부분은 CPU(중앙처리장치)와 RAM(주기억장치), 그리고 하드디스크(보조기억장치)다. 이 세가지 요소의 성능이 고르게 향상되어야 실질적인 처리 속도의 향상을 체감할 수 있다. 다만, 반도체 기반의 장치인 CPU와 RAM에 비해 자기디스크 기반 장치인 하드디스크는 데이터 처리 속도가 뒤떨어 질 수밖에 없었고, 이 때문에 PC 전체의 성능을 향상시키는데 걸림돌이 되곤 했다.

하드디스크의 속도가 느린 이유는 장치 자체의 재질과 구조 때문이기도 하지만, 인터페이스(interface: 연결 방식)의 문제도 있었다. 1980년대 PC 개발 초기부터 써온 병렬 ATA(Parallel AT Attachment, 통칭 ‘IDE’, 혹은 ‘PATA’) 방식의 인터페이스는 2000년대 초반까지 하드디스크 및 ODD(광디스크 드라이브)용 인터페이스로 널리 쓰였다. 시간이 지나면서 PATA 인터페이스도 몇 번의 개량을 거쳐 약간의 성능 향상이 있었지만, 데이터 전송 속도 면에서 이미 한계를 드러내고 있었다.

PATA(IDE)를 대체하기 위해 태어난 SATA 인터페이스

PATA 인터페이스는 속도뿐 아니라 편의성 면에서도 불리했다. 데이터의 경로를 여러 개로 분산시켜 성능을 높이는 병렬 구조의 특성 때문에 PATA 방식의 하드디스크와 ODD는 40개의 핀으로 구성된 복잡한 구조의 커넥터와 케이블을 사용해야 했고(후기에는 80선 규격의 PATA 케이블이 나오기도 했다), 이는 장치 및 케이블을 소형화 하는데 불리했다. 게다가 지나치게 많은 핀을 사용하다 보니 데이터 전송 도중에 신호의 누락이나 오류가 발생할 여지가 컸고, 이는 데이터 전송 시 안정성과 속도를 저하시키는 요인으로 작용했다.

1986년에 PATA보다 데이터 안정성과 전송속도를 향상시킨 SCSI(Small Computer System Interface: 스커지) 인터페이스가 발표되었지만, 표준 규격이 완전히 확립되지 못하고 장치의 가격이 비싸서 PC보다는 서버나 워크스테이션용으로만 보급되는데 그쳤다.
이러한 이유로, PATA 인터페이스의 한계를 극복하고 하드디스크 및 ODD의 성능을 향상시키기 위한 새로운 표준 인터페이스를 원하는 목소리가 점차 커졌고, 그 결과물로 나온 것이 바로 2003년에 처음으로 규격이 재정된 ‘직렬 ATA(Serial ATA)’ 인터페이스다. 통칭 ‘SATA’, 혹은 ‘사타’로 부르는 이 인터페이스는 이름에서 볼 수 있듯, 기존의 PATA와 달리 직렬 구조의 데이터 전송 방식을 갖추고 있다.

크게 향상된 편의성과 안정성

40개의 접점을 사용하는 PATA와 달리, SATA는 커넥터의 접점이 7개로 줄어들었으며 이로 인해 포트의 크기와 케이블의 굵기를 크게 줄일 수 있었다. PATA용 데이터 케이블은 너비가 5cm에 육박하지만 SATA용 케이블의 너비는 8mm에 불과하므로 PC 내부 공간을 그만큼 절약할 수 있으며, 케이블 및 포트의 생산 비용도 낮출 수 있게 되었다. 이와 함께, PATA 환경에서는 전송 오류 발생의 우려 때문에 케이블의 최대 길이가 40 ~ 50cm 정도로 제한되었지만, SATA 환경에서는 1m에 달하는 긴 케이블을 쓸 수 있다.



그리고 병렬 구조의 PATA 인터페이스에서는 하나의 케이블에 2개의 하드디스크나 ODD를 함께 연결한 뒤, 각 장치에 꽂힌 점퍼(jumper, 커넥터의 일종)의 배치에 따라 이를 구분해 사용하는 마스터/슬레이브(Master/Slave) 개념이 있었지만, 직렬구조인 SATA 인터페이스에선 이런 개념 없이 각 디스크가 각각의 포트와 케이블을 사용해 메인보드(주기판)와 직접 연결된다. 이로 인해 2대 이상의 디스크를 함께 설치할 때 점퍼나 케이블의 조정을 해줄 필요가 없게 되었다.

그 외에, PATA 환경에서는 하드디스크를 교체할 때 반드시 PC의 전원을 꺼야 했지만, SATA 환경에서는 전원이 켜진 상태에서도 하드디스크의 교체가 가능한 핫 스와핑(hot swapping) 기능을 지원한다. 다만, 모든 PC에서 SATA 하드디스크의 핫 스와핑이 가능한 것은 아니며, 해당 PC의 메인보드 및 운영체제에서 AHCI(Advanced Host Controller Interface) 규격을 지원해야 가능하다.

그리고 SATA 규격은 기본적으로 PC 내부에 설치되는 내장형 하드디스크를 위한 것이지만, 휴대용 외장형 저장장치인 외장하드를 위한 별도의 SATA 규격도 지정되어 있다. 외장형 SATA 규격은 ‘eSATA’라고 하는데, 내부적으로 전송되는 데이터는 일반 SATA와 동일하다. 다만, 커넥터 및 케이블의 규격은 일반 SATA와 다른 것을 사용하며, 최대 2m에 이르는 긴 케이블을 사용할 수 있다는 점이 특징이다.

최대 6Gbit/s의 속도로 데이터 전송 가능

위와 같이 SATA 인터페이스는 PATA 인터페이스에 비해 많은 장점을 가지고 있지만, 그 중에서도 가장 눈에 띄는 것은 바로 데이터 전송 속도가 향상되었다는 점이다. PATA 규격의 경우, 실질적으로 마지막 규격이라고 할 수 있는 Ultra ATA/133 모드에서 최대 1.33Gbit/s의 속도를 낼 수 있었지만, SATA의 경우, 2003년에 등장한 첫 번째 규격부터 최대 1.5Gbit/s의 속도를 낼 수 있었다.
이후 SATA 규격의 데이터 전송속도가 점차 향상되어 2005년, 최대 데이터 전송 속도가 3.0Gbit/s로 빨라진 ‘SATA 리비전(Revision) 2.0’ 규격이 발표되었으며, 2008년에는 6Gbit/s의 최대 전송 속도를 내는 ‘SATA 리비전 3.0’ 규격이 발표되었다. 2011년 현재, 시장의 주류를 이루고 있는 것은 SATA 리비전 2.0 규격의 제품들이지만, SATA 리비전 3.0 규격을 지원하는 메인보드 및 하드디스크가 다수 출시되고 있어 조만간 대체될 것으로 전망되고 있다.

SATA의 각 버전은 같은 모양의 포트와 커넥터를 사용하며, 내부적으로도 하위호환성을 갖추고 있어 서로 버전이 다른 하드디스크 및 메인보드를 함께 사용하는 것도 가능하다. 다만, 이 경우는 양쪽 제품 중 하위 버전의 성능으로 동기화된다. 예를 들어 SATA 리비전 3.0 규격의 하드디스크와 SATA 리비전 2.0 규격의 메인보드를 함께 사용할 경우, 전체 성능이 SATA 리비전 2.0 수준으로 낮아지게 된다. 참고로 시중에는 다소 가격이 비싼 SATA 리버전 3.0 규격 전용 케이블이라는 제품이 팔리고 있긴 하지만 벤치마크(성능 측정) 프로그램 사용시, 기존 SATA 케이블에 비해 약간의 수치 변화가 있을 뿐, 체감적인 성능 차이는 거의 없으므로 일부러 이를 구매할 필요는 없다.

SATA3? SATA 3.0? SATA 6Gbit/s? 뭐라고 부르지?

SATA 리비전 3.0 규격은 현재 시장에서 SATA3, SATA 3.0, SATA 6Gbit/s 등 다양한 명칭으로 표기되고 있다. SATA 규격의 표준을 관장하는 ‘SATA-IO(Serial ATA International Organization: SATA 국제 협회)’에서는 ‘SATA 리비전 3.0’, 혹은 ‘SATA 6Gbit/s’로 부를 것을 권장하고 있지만, 시장에서는 편의상 ‘SATA3’, 혹은 ‘SATA 3.0’이라고 지칭하곤 한다. 다만, 이 경우엔 SATA 3.0Gbit/s(SATA 리비전 2.0) 규격과 혼동할 우려가 있으므로 제품 구매 시 주의하는 것이 좋다.
그리고 상위 규격의 SATA 하드디스크를 쓴다 하여 PC의 전반적인 속도가 몇 배로 빨라지기를 기대하는 것은 바람직하지 않다. 인터페이스 속도의 발전에 비해, 하드디스크 자체의 속도 발전은 상대적으로 더디게 이루어지고 있기 때문이다. 때문에 SATA 리버전 3.0은 일반 하드디스크가 아닌 SSD(Solid State Drive: 반도체 기반의 저장장치)에 적용했을 때 훨씬 효과적이라는 것이 일반적인 평가다.

48-bit Address Feature Set

 초기의 저장 장치는 용량이 작아서 28bit면 모든 영역에 대해 sector 주소 지정을 할 수 있었음
  - 2^28 = 256M, 256M*512B(sector 당 크기) = 128GB까지 주소지정가능

 하지만, 최근에는 128GB를 상회하는 저장장치가 쏟아져 나오면서 28bit command로는 128GB를 넘는 영역에 대해 access를 할 수 없게 됨

 => 이 문제를 해결하기 위해 48 bit command가 만들어졌고 이를 위해 각 field별로 8bit가 아닌 16bit로 할당

주소할당하기 위한 field
LBA High      8  -> 16 bit
LBA Middle  8  -> 16 bit
LBA Low      8  -> 16 bit
device 하위  4
--------------------------
                   28  -> 48 bit

 따라서 각 field에 대한 달라진 구성은 아래와 같음 (실제 데이터 전송은 아래와 같은 방식이 아니므로 개념만 이해) 차이점은 feature, sector count, LBA Low/Mid/High에 대해서는 16bit로 늘어났고 device의 하위 4bit에 대해서는 LBA로 할당하다가 reserved로 변했음을 알 수 있다.

[28bit Read DMA command에 대한 TFR 구성] 

[48bit Read DMA Extended command에 대한 TFR 구성]

 실제적으로 데이터 전송은 아래 그림과 같이 이루어짐