Home

낸드 플래시 메모리는 플로팅 게이트 기반의 반도체 소자를 집적하여 구성한 비휘발성 반도체 저장장치이며, 주요 구성요소로는 읽기 및 쓰기 단위인 페이지, 지우기 단위인 블록 단위가 있다. 페이지 크기는 주로 4KB, 8KB, 16KB 정도이며, 수십 개의 페이지가 모여서 하나의 블록을 구성한다. 낸드 플래시 메모리는 집적도의 향상으로 저장 용량은 큰 증가를 이루었지만, 인접 셀 간의 간격이 좁아지고, 하나의 셀 당 저장할 수 있는 저장 단위의 증가로 인해서 셀 간의 간섭도가 증가하였으며, 이로 인해서 읽기 및 쓰기 도중에 발생할 수 있는 오류도 급격히 증가하게 되었다. 일반적으로 낸드 플래시 메모리의 수명을 나타내는 지표인 P/E cycle 값이 SLC(Single Level Cell)의 경우 100,000 정도이나, MLC(Multi Level Cell)의 경우 10,000 이하, TLC(Triple Level Cell)의 경우 수천 이하로 급격히 에러 발생률이 늘어가고 있으며, 낸드 플래시 메모리 기반 저장장치의 수명이 주요 이슈로 주목받았다. 이러한 에러에 대처하는 방안으로 BCH, LDPC와 같은 ECC 방법이 낸드 플래시 메모리 컨트롤러에 내장되고 있으며, RAID-5와 같은 블록 수준 또는 칩 수준의 에러 복원 기술이 적용되고 있다.

본 논문의 스트라이프 로그 아키텍처의 설계 목표는 RAID-5를 지원하는 플래시 스토리지 시스템의 패리티 업데이트 오버헤드를 최소화하는 것이다. 읽기 및 쓰기 요청에 대한 다른 모든 일반 작업은 기존 RAID-5 플래시 스토리지 시스템과 동일하다. 이는 FTL(Flash Translation Layer)[9] 매핑 테이블과 같은 플래시 스토리지 관리를 위한 필수 메타 데이터 아키텍처가 다른 플래시 시스템과 유사하거나 다른 플래시 시스템으로 대체 될 수 있음을 의미한다. 매핑 테이블 관리는 이 논문의 주요 문제가 아니며, 이 논문의 주요 디자인 문제는 패리티 업데이트 오버헤드를 최소화하면서 RAID-5를 지원하도록 하는 메타데이터(Metadata) 로깅 아키텍처 및 해당 메타데이터 작업을 설계하는 방법이다.

전체적인 메타 데이터 아키텍처는 그림 1에 도식화 하였다. 그림과 같이 본 논문에서 설계한 전체 메타 데이터 구조는 Root 블록, Stripe Map 블록, PageMap 블록 및 StripeMapLog 블록 등으로 구성된다. NAND 플래시 메모리 내에 저장되는 이러한 메타데이터 블록에는 메타데이터의 스냅샷(Snapshot) 상태가 포함되어 있으며, RAM과 같은 메인 메모리에는 낸드 플래시 메모리 스냅샷 이후에 스토리지 연산에 의해서 업데이트 된 최신 메타데이터 정보가 기록되어 있다. 각각의 메타데이터 블록의 의미는 다음과 같다.

Fig. 1. 
Stripe metadata and Log architecture for RAID-5 support

Root 블록에는 메타데이터 블록 (예: StripeMap 블록, PageMap 블록 및 StripeMapLog 블록)이 저장된 블록 번호가 기록된다. StripeMap 블록에는 각 스트라이프 데이터 그룹 블록 및 스트라이프 그룹 정보가 기재되어 있다. 본 논문에서 스트라이프 그룹은 패리티 클러스터를 구성하는 블록 그룹을 의미한다. 스트라이프 사용정보를 나타내기 위해서, BlkInfo[], StripeInfo[] 및 StripeInfoList[]등 세 가지 데이터 구조가 존재한다. 자세한 내용은 다음 장에서 설명한다.

본 논문에서 적용한 FTL의 매핑 테이블 관리 방법은 페이지 각각에 대한 페이지 수준의 매핑 관리를 사용하며, 이는 각 논리적 페이지가 각 물리적 페이지에 할당되어 있음을 나타낸다. 즉, NAND 플래시 메모리 내의 PageMap 블록에는 논리 페이지와 실제 페이지 간의 페이지 수준 매핑 정보 스냅샷이 포함되어 있으며, RAM 영역의 페이지 매핑 테이블은 최신 매핑 정보를 유지한다.

본 논문에서 설계하는 로깅 전략은 데이터 로깅이 아닌 메타 데이터 로깅을 위한 것이다. 따라서 데이터 쓰기가 발생할 때마다 해당 쓰기 데이터는 낸드 플래시 미디어 쓰기 연산이 수반되며, 이에 더해서 해당 쓰기 연산과 관련된 메타 데이터의 로깅 작업 및 패리티 업데이트 작업을 추가로 설계한 것이다. 본 시스템에서, RAID-5 아키텍처의 패리티 데이터는 스트라이프의 페이지 레벨에서 계산된다. RAID-5에 대한 부분 페리티 연산과 스트라이프 그룹의 기록 동작에 대한 흐름도를 그림 2에 나타내었다.

Fig. 2. 
Flowchart of logging operations StripeMapLogInfo and partial parity for RAID-5

그림에 나타난 바와 같이, 스트라이프에 대한 패리티는 전체 스트라이프 쓰기가 완료될 때까지 버퍼 메모리에 유지되는 반면, 스트라이프의 데이터 영역은 전체 스트라이프 쓰기가 완료되는 것과 관계없이 기록된다. 플래시 저장장치의 쓰기는 항상 스트라이프 영역의 새로운 영역에 발생하며, 이에 대해서 패리티가 업데이트되므로 스트라이프의 부분 패리티를 업데이트하기 위해 이전 데이터를 읽을 필요가 없다. 마지막에, 전체 스트라이프가 완료되면 해당 스트라이프에 대해 완성된 패리티가 플래시 미디어에 쓰이게 된다.

부분 패리티의 경우 메모리에 유지되므로 정전으로 인해 손실될 수가 있다. 정전에서 부분 패리티를 복구하기 위해 스트라이프 로깅이 적용된다. 설계된 로깅 시스템에서 현재 스트라이프에 대한 매핑 변경 사항은 StripeLogInfo의 구조로써 메모리 영역에 존재한다. 현재 스트라이프 그룹 StripeMapLogInfo의 매핑 로그 정보는 해당 스트라이프의 데이터 쓰기 영역이 완료되어 해당 스트라이프의 패리티가 플러시 될 때, 전용 플래시 블록에 StripeMapLog의 형태로 페이지 단위로 플러시 된다. 만약, 패리티가 버퍼에 보유된 부분 상태에 있는 동안 전원 손실이 발생하면, 메모리에 로깅된 정보 역시 분실된다. 그러나 이 메타정보는 정전이 발생하기 직전 쓰기가 진행중이었던 스트라이프의 플래시 메모리 OOB(Spare) 영역에 기재가 되어 있기 때문에, 해당 스트라이프 영역을 스캔하여 해당 부분 패리티를 복구할 수 있다. 세부적인 동작 방식은 다음 장에서 설명한다.

앞장에서 설명한 대로 전체 메타 데이터 구조가 그림 1에 표시되어 있다. 그림에 나타난 바와 같이, 플래시 메모리 블록 0 또는 1 둘 중에서 하나가 피벗 루트 블록으로 사용된다. 처음 시작 시, 블록 0이 루트 블록에 할당된다. 루트 블록의 마지막 업데이트된 페이지에는 메타데이타의 정보가 기록된 블록들의 위치가 있는 RootInfo 값을 가지고 있다. 메타 블록이 변경될 때마다 RootInfo는 Root 블록의 한 페이지에 로그 방식으로 업데이트된다. 업데이트가 현재 루트 블록의 마지막 페이지 (예 : 블록 0)에 도달하면 루트 블록이 블록 1로 변경되고 업데이트가 계속된다. StripeMap 블록에는 각 스트라이프, 데이터 블록 및 스트라이프 버킷 정보가 기록된다. 스트라이프 사용현황 등의 정보를 위해서 BlkInfo[], StripeInfo[] 및 StripeInfoList[]의 세 가지 데이터 구조가 있다. BlkInfo[]는 각 데이터 블록에 대한 상태 정보를 가지며, StripeInfo[]는 각 스트라이프 그룹의 상태 정보를 가지고 있다. 스트라이프 그룹의 크기는 해당 스트라이프에 포함된 데이터 블록의 개수이다. 예를 들어, 스트라이프 크기가 ​​S이면 하나의 스트라이프 그룹은 S 블록으로 구성된다. StripeInfoList[]는 0에서 (S*N)까지 버킷을 갖는 해시 데이터 구조이다. 여기서 N은 스트라이프 그룹 내 유효한 페이지 수이다. 각 버킷에는 같은 유효한 페이지 수를 가진 이중 연결 스트라이프 그룹 목록이 있다. 이 목록을 사용하여 다음 쓰기를 위한 프리 스트라이프 그룹과 GC가 필요할 때 수행할 희생 스트라이프 그룹을 선택할 수 있다. PageMap 블록은 페이지 매핑 테이블 정보를 가진다. 페이지 매핑 테이블의 각 항목은 실제 페이지 번호 (PPN)의 배열이다. 메타 데이터의 마지막 부분은 StripeMapLog 블록으로, 쓰기에 대한 메타 데이터 정보를 로깅 하는 데 사용된다.

NAND 플래시 메타 블록은 최신 버전의 스냅샷을 나타내며 메인 메모리에는 스냅샷 이후에 변경된 최신 메타 데이터 정보가 있다. 쓰기가 발생할 때마다 모든 데이터가 플래시 스토리지 시스템의 새로운 클린 영역에 기록되므로 메타데이터가 업데이트가 발생한다. 변경된 메타데이터 정보는 특정 시점마다 낸드 플래시 메모리로 보내져서 최신 메타데이터 정보를 유지할 수 있도록 한다. 이렇게 보내지는 정보가 로그 정보이다.

사용자의 쓰기 연산에 대한 전체적인 로그 동작의 흐름도가 그림 2에 도식화되어 있다. 최신 스냅샷 이후, 업데이트되는 메타 데이터 정보는 메모리 내 StripeMapLogInfo 구조 정보를 생성하여 차례로 기록되며 일정량의 메타 데이터 업데이트로 채워지면 StripeMapLog 블록에 하나 이상의 페이지로 스트라이프를 구성하여 낸드 플래시 메모리에 로그 형태로 플러시(Flush) 된다. 만약, StripeMapLog 블록 로딩된 페이지로 가득 차면 로깅 할 공간이 없게 되어, 다음 사용 가능한 블록 영역이 필요하다. 새로운 StripeMapLog 블록을 할당하기 전에 메인 메모리 내 메타 데이터 정보가 NAND 플래시 메모리에 동기화되어 최신 스냅샷이 된다. 그 후 새로운 StripeMapLog 블록 할당한다. 이 과정을 거친 후, 앞서 설명한 통상적인 로깅 메커니즘이 수행된다.

StripeMapLogInfo는 스트라이프 그룹에 있는가각 스트라이프의 논리적 주소에 대한 배열로 구성되며 논리적-물리적 매핑 정보를 가지게 된다. 스트라이프 그룹은 RAID 스트라이프를 구성하기 위해 그룹화된 블록 그룹이다. 스트라이프 그룹은 블록 레벨이지만 스트라이프에 대한 패리티는 그룹 내의 페이지 레벨이다. 예를 들어서 4개의 블록으로 스트라이프를 구성할 경우, 패리티는 그룹 내에서 같은 페이지 오프셋을 가진 3개의 페이지를 기반으로 생성된다. 메타 데이터 로깅 절차는 다음과 같다. 새로운 쓰기가 발생할 때마다 새 데이터가 스트라이프 그룹 내의 새 페이지에 할당된다. 그런 다음 이 스트라이프의 물리 페이지에 대한 논리-물리 주소 매핑 쌍 값들이 메모리의 StripeMap LogInfo에 기록된다. 한편, 데이터가 플래시 페이지에 기록될 때 LPN은 페이지의 OOB(Spare) 영역에 저장되는데, 이는 전원 손실 복구 및 갑작스런 전원 손실로 인한 패리티 복구에 중요하다.

로그 변경 외에도 StripeMapLogInfo에는 다음 스트라이프 그룹에 대한 정보를 가지고 있는데, NextLogType 및 NextStripe 또는 SrcStripe 및 DstStripe이라는 필드에 해당 정보를 가지고 있다. NextLogType은 현재가 아닌 다음 로그의 유형을 나타낸다. 스트라이프 그룹 변경에는 두 가지 유형이 있는데, 하나는 사용자 데이터 쓰기를 위한 스트라이프 그룹이고 다른 하나는 GC를 위한 스트라이프 그룹이다. 이에 따라 두 가지 유형의 로그가 있다. NextLogType이 0이면 다음 로그 유형은 사용자 쓰기이며 정상적인 쓰기 요청에 대해 다음 스트라이프가 선택되며, NextLogType이 1이면 다음 로그 유형은 GC이며 GC 작업을 위한 소스 스트라이프 및 대상 스트라이프가 선택된다. NextLog 유형 및 다음 스트라이프 그룹의 정보는 시스템 복구 시 중요한 역할을 한다. NextLogType을 설정하는 방식은 다음과 같다. 현재 쓰기 요청에 대해서 새 스트라이프 그룹이 필요할 경우, 사용 가능한 스트라이프 그룹 풀에서 새 스트라이프 그룹을 선택한다. 스트라이프 그룹 풀에 프리 스트라이프 그룹이 있어서 이를 선택하면 선택된 스트라이프 그룹 넘버를 StripeMapLogInfo 구조의 NextStripe 필드에 기록하며 NextLogType을 0으로 설정한다. 만약, 사용 가능한 스트라이프 그룹이 충분하지 않은 경우, 특정 스트라이프 그룹을 다시 확보하기 위해 회수해야 한다. 이 경우가 GC에 해당하며, 이때, GC에 필요한 GC 희생 스트라이프 그룹과 희생 그룹으로부터 옮겨갈 목적지 스트라이프 그룹을 선택한다. 선택한 희생 스트라이프는 SrcStripe에, 목적지 스트라이프는 DstStripe에 기록된다.

메모리에 유지되는 부분 패리티는 정전으로 인해 손실될 수 있는데, 이는 기록 된 메타 데이터로 복구할 수 있다. 풀 스트라이프 쓰기에 대한 패리티 상태로 거의 패리티 데이터가 플래시 메모리에 저장되므로, 풀 스트라이프에 대한 패리티는 복구할 필요가 없고, 부분 스트라이프 쓰기 도중 전원이 복구할 실제 부분은 부분 패리티와 관련된 스트라이프 영역만 복구해주면 된다.

부분 패리티 복구 단계는 다음과 같다. 먼저, 부팅의 첫 번째 단계에서 SSD는 Root 블록을 스캔하여 최신 RootInfo를 찾는다. 두 번째 단계에서는 StripeMap 및 PageMap 블록을 검색하여 StripeInfo List[], StripeBlkInfo[], BlkInfo[] 및 페이지 매핑 테이블로 구성된 메타 데이터 스냅샷을 읽어서 스냅에 대한 메타데이터를 복원한다. 세 번째 단계에서는 StripeMapLog 블록에 저장된 메타 데이터 변경 사항이 복구된다. 이후의 단계가 부분 패리티를 복구하는 단계이다. 마지막 단계에서 StripeMapLog 블록에 기록되지 않은 매핑 변경 사항을 복구하고, 이와 관련된 부분 패리티를 복구함으로써 복구가 마무리되는데, 이는 마지막 StripMapLog 블록의 마지막 유효 페이지의 StripeMapLogInfo에 기재되어 있는 NextStripe에 해당하는 스트라이프 그룹을 스캔함으로써 이 작업이 가능하다. 이 NextStripe에 해당하는 스트라이프 그룹이 바로 쓰기 연산을 수행하다가 전원 손실이 발생한 스트라이프 그룹이기 때문이다. 먼저, NextStripe의 메타데이터 변경 사항은 해당 스트라이프 그룹의 각 페이지의 스페어 영역(OOB)을 스캔하여 복구할 수 있다. 이는, 각 페이지의 스페어 영역에 해당 페이지의 논리 주소(LPN)이 적혀 있기 때문이다. 모든 스트라이프 페이지 스캔에 대해 모든 페이지에 유효한 논리 주소가 있으면 전체 스트라이프가 안전하게 저장되고 해당 패리티도 안전하다는 의미이다. 유효한 LPN 정보를 가지는 페이지에 대해서는 그와 연관된 메타 데이터를 업데이트하여 준다. 일부 페이지에 유효한 논리 주소가 없으면 이 스트라이프의 모든 데이터가 유효하지 않기 때문에 이 스트라이프에 대한 완전한 전체 스트라이프 패리티가 없다. 즉, 부분 패리티를 메모리에 유지하던 도중 전원 손실이 발생하였다는 의미이다. 이 경우, 해당 스트라이프의 각 유효한 페이지를 검색하여, 유효한 페이지의 데이터를 읽어 패리티 연산을 해줌으로써 부분 패리티를 복구할 수 있다, 이렇게 함으로써 최종적으로 전원 손실에 대한 복구를 수행할 수 있게 된다.