정말 오랫만에 다시 씁니다. 회사가 팔려가는 입장이라 마음이 뒤숭숭한 것은 전혀 핑계가 아니고, 누가 이런 글을 보겠냐는 생각에 게으름 피우느라 잠시(?) 쉬었습니다. 이제 회사 매각에 대한 정리도 어느 정도 되가는 편이고, 또 놀다가 지쳐서 뭔가 시간 때우기 좋을 만한 꺼리를 찾다가 발견하여 다시 시작하는 것이 아님을 강조하는 바입니다.
너무 오래되서 제가 어디까지 썼나 되뇌어 봤는데 제가 써놓고도 중구 난방이라 이어 쓰기가 상당히 어렵네요. 대충 보니 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의 진행 상황 또는 종료 상황 등의 정보를 담고 있습니다. 각각의 의미는 아래와 같습니다.
간단한 내용이니 그냥 넘어가도록 하겠습니다.
세 번째 item(363)은 self test의 세부적인 상태를 보여줍니다. 이것도 표에서 상세하게 설명하고 있으니 그냥 넘어가도록 하겠습니다.
다섯 번째(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의 구성도 이와 같습니다. 일단 아래 표를 보시죠.
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
댓글 없음:
댓글 쓰기