NAND spare 영역을 metadata로 꽉 채우면 ECC와 충돌한다

NAND page에는 user data 뒤로 spare 영역이 붙는다. 이름 때문에 남는 공간처럼 보이지만, 전부 application metadata로 채우면 내부 ECC나 factory 관리 정보와 충돌할 수 있다. NAND OOB는 out-of-band 영역이며, byte마다 역할과 보호 규칙이 다를 수 있다.

필요한 것은 spare의 총 크기보다 내 metadata를 써도 되는 위치와 그 정보가 어떤 방식으로 보호되는지다. 용량 계산과 layout 확인은 따로 해야 한다.

128byte spare를 실제 구간으로 나누기

Alliance Memory SPI NAND Rev.1.0의 1.4절 Table 1-3은 main data 2048byte에 spare 128byte가 있는 구성을 설명한다. 여기서는 이 표의 주소 layout과 내부 ECC 사용을 전제로 한다.

main data는 0x000–0x7FF다. spare 전체는 0x800–0x87F이지만, 마지막 0x848–0x87F의 56byte는 internal ECC parity 영역이다. ECC를 켠 상태에서는 이 영역을 일반적인 metadata 저장 공간으로 사용할 수 없으며, 문서는 읽을 때 FFh가 보이는 동작을 명시한다.

앞쪽 0x800–0x847은 네 metadata 구간이다. 각 구간은 18byte이고 처음 4byte는 ECC 비보호, 뒤 14byte는 ECC 보호로 나뉜다. 첫 구간만 적으면 0x800–0x803이 비보호이고 0x804–0x811이 보호다. 다음 구간도 같은 크기로 이어진다.

합계는 16byte 비보호 metadata, 56byte 보호 metadata, 56byte internal parity로 128byte다. spare가 모두 같은 성질을 갖는다는 가정부터 버려야 표를 올바르게 읽을 수 있다.

크기는 충분한데 주소가 충돌하는 예

60byte의 자체 metadata를 저장하려고 column 0x800부터 연속으로 채운다고 하자. 마지막 주소는 0x83B다. internal parity 시작인 0x848에는 닿지 않는다. 그렇다고 바로 안전한 layout은 아니다.

block의 첫 page라면 13절의 factory bad marker를 확인하는 첫 spare byte가 0x800이다. 이를 application 값으로 바꾸면 이후 block 판정과 충돌할 수 있다. 또한 앞의 네 비보호 구간이 모두 들어 있으므로 “60byte 전체를 on-die ECC가 고쳐 준다”는 설명도 틀리다.

첫 page에서 byte 0x800을 제외하면 앞쪽 metadata 주소는 단순 수량상 71byte 남는다. 하지만 71byte 전부를 자유롭게 사용할 수 있다고 결론내릴 수는 없다. 다른 관리 정보와 상위 driver의 예약 위치, program 방식까지 확인해야 한다. 60byte가 들어간다는 사실은 그중 한 조건일 뿐이다.

보호되는 정보와 보호되지 않는 정보를 읽는 법

논리 주소, sequence number, checksum 같은 정보도 중요도가 다르다. payload만 올바르게 읽혀도 mapping metadata가 틀리면 다른 위치의 data로 해석할 수 있다. metadata를 어떤 오류 범위에서 복원하거나 검출할지 정하고 적합한 영역과 별도 보호 수단을 선택해야 한다.

이 표의 “ECC protected”는 해당 byte에 내부 ECC 보호가 적용된다는 의미다. 전체 storage transaction의 일관성을 보증하지는 않는다. 전원 차단으로 metadata 일부만 갱신되거나 새 page와 이전 mapping이 섞이는 문제는 bit correction과 다른 문제다.

반대로 비보호 구간이라는 사실이 읽을 수 없는 영역이라는 뜻도 아니다. 원래의 marker처럼 별도 용도로 의도된 byte일 수 있다. decoder가 자동으로 보정하지 않는다는 조건을 metadata format이 알고 있어야 한다.

FFh 출력이 실제 자유 공간을 뜻하지 않는다

internal parity 영역을 읽었더니 FFh가 보인다고 “비어 있으니 사용하자”고 판단하면 안 된다. 내부 ECC를 켠 mode에서 장치가 host에 보여 주는 값과 실제 parity 저장 동작은 다를 수 있다. layout은 읽힌 pattern만으로 역추정하지 않는다.

ECC를 끄는 경우에도 같은 주소들이 즉시 안전한 user spare가 된다고 가정하지 않는다. 해당 mode에서 누가 parity를 만들고, raw 오류를 어떻게 처리하며, marker와 기존 data format을 어떻게 보존하는지를 정해야 한다. on-die ECC 설정은 출력 status와 data 해석의 일부다.

driver와 상위 저장 format이 다른 OOB 배치를 기대하면 main data가 정상이어도 mount나 recovery가 실패할 수 있다. page당 byte 수뿐 아니라 보호 단위와 예약 주소를 맞춰야 서로 같은 record를 읽는다.

NAND OOB는 자투리 용량이 아니라 data를 해석하고 복원하기 위한 별도 인터페이스다. 주소 구간별 소유자·ECC 보호·갱신 규칙을 확인한 뒤 metadata를 배치하면, spare가 넉넉한데도 저장 정보가 충돌하는 이유를 설명할 수 있다.