필요성 사실 이 파트에서는 필요성을 굳이 설명할 이유가 있을까 싶다. 디스크 관리 도구의 존재 의의이기 때문이다. 제품의 수명을 관리하고, 사용자가 놓치기 쉬운 이상 증상들을 확인하는 일은 모두 여기서 시작된다. 따라서 이번 글에서는 글을 다른 구성으로 가고자 한다. S.M.A.R.T: 자가 진단, 분석, 보고 기술 이 기술은 이름이 말하는 대로, 저장 장치가 스스로 분석하고 진단해서 문제가 있는지 […]
Tag Archives: Windows
나래온 툴 내부 구조 – 6. SATA 장치에서 기본 정보 가져오기
필요성 지난 시간에 ACS-3를 둘러보면서, 개념들과 SATA 장치에 어떻게 명령해야 하는지에 대한 방법을 살펴보았다. 이번 시간에는 나래온 툴에서 장치의 기본 정보를 얻어올 때 쓰는 명령어 구현을 살펴보자. Identify (Identify device) 4편에서 Identify에 대해 다음과 같이 설명한 적이 있다. BIOS나 장치 관리자에 나오는 장치 이름, 펌웨어 버전, 시리얼 번호, 용량 등은 다 여기서 가져오는 것이다. 요약하면, […]
나래온 툴 내부 구조 – 5. SATA 명령어 개요
필요성 NVMe 장치가 널리 퍼지긴 했지만, 여전히 SATA 장치는 저장장치의 대다수를 이루고 있다. SSD의 상당수가 SATA 인터페이스로 PC와 연결되며, HDD 역시 SATA로 연결된다. 따라서 이들의 정보를 가져오는 데에 이들의 언어인 ACS(ATA Command Set)는 필수적이다. 나래온 툴 역시 모든 구현의 기준은 SATA이며, 다른 장치에서 나온 결과는 SATA 형식으로 변환을 거치게 하는 식으로 동작하고 있다. 리팩토링 당시에 […]
나래온 툴 내부 구조 – 4. 명령 집합과 버퍼 해석
필요성 사람들이 이 블로그에 찾아오는 이유는 여기에 있을 가능성이 높다고 생각한다. Read, Write, Open, Close가 아닌 모든 명령어가 들어가는 곳, ioctl. 정확히는 윈도우에서 DeviceIoControl이라고 부르는 그 API다. 학부 시절에 잘 하면 존재 정도는 들었을 이 API로 모든 명령이 오간다. 나 역시 처음 들었을 때는 매우 막연해서 어디에서 자료를 찾아야 할지도 잘 몰랐다. 이 편부터는 그 […]
나래온 툴 내부 구조 – 3. 물리 드라이브 추상화
필요성 물리 드라이브 자체는 수많은 기능을 가지고 있다. 이들 중 나래온 툴에서 필요한 부분을 객체로 추상화한 것이 TPhysicalDrive이다. 내부를 보면 사실 이 객체는 요청들을 두 방향으로 전달만 하는데, 버스에 직접 요청하는 것(ATA, SCSI, NVMe, …)과 다른 API에 기반한 것들을 따로 관리하고 있다. 전자가 TBusPhysicalDrive, 후자가 TOSPhysicalDrive이다. 왜 인터페이스인가? 이 객체는 TPhysicalDrive 자체로 쓰이는 일은 없고 대부분 IPhysicalDrive […]
나래온 툴 내부 구조 – 2. 경로가 지정된 객체들
필요성 나래온 툴에는 경로가 필요한 객체들이 많다. 대표적으로 물리 드라이브 그 자체인 TPhysicalDrive부터, 수많은 Getter 객체들이 모두 해당 드라이브의 경로를 필요로 한다. 이외에도 파티션을 지정하는 객체의 경우에도 경로를 필요로 한다. 이 경우 각 행동을 수행할 때마다 경로를 기입하게 하는 것은 부자연스러울 뿐더러 혼동의 가능성이 매우 크다. 따라서 객체가 생성될 때 경로를 지정하고 내부에서 경로를 보관하게 […]
나래온 툴 내부 구조 – 1. 물리 드라이브 목록 가져오기
들어가기에 앞서 이 시리즈는 나래온 툴의 내부 구조를 정리하여, 해당 프로그램의 일부 기능을 구현하는 사람들에게 도움을 줄 목적으로 작성되었다. 따라서 이 글은 그동안 질문 받았던 부분을 중심으로 쓰게 될 것이다. 더 궁금한 점이 있으면 메일로 문의하면 된다. 다만 코드 스니펫의 델파이 -> C++ 번역 요청은 받지 않는다. 필요성 디스크 툴이 처음 시작할 때 가장 먼저 하는 […]