Flash_Memory_and_SSD

Kamator0·2026년 6월 8일

Flash Memory and SSD

Characteristics of Flash Memory — 플래시 메모리의 특성

NAND 플래시 메모리의 물리적 구분

NAND 플래시 메모리는 HDD의 "섹터/트랙/실린더"와는 완전히 다른 물리적 단위를 갖는다. 핵심은 읽기/쓰기 단위와 삭제 단위가 다르다는 것이다.

단위	영문	크기	역할
페이지	Page	512 bytes (또는 4KB 등)	읽기/쓰기(access)의 최소 단위
블록	Block	수 KB ~ 수백 KB (예: 128KB)	삭제(erase)의 최소 단위

핵심 포인트: 하나의 블록은 여러 페이지로 구성된다. 예를 들어 128KB 블록 안에 512B 페이지가 256개 들어 있다. 읽거나 쓸 때는 페이지 단위로 하지만, 지울 때는 반드시 블록 전체를 한꺼번에 지워야 한다. 이것이 플래시 메모리 설계의 모든 복잡성의 근원이다.

접근 시간 (Access Times)

연산	시간	비고
페이지 읽기 (Read)	25 us	가장 빠름
페이지 쓰기 (Write/Program)	226 us	읽기의 약 9배 느림
블록 삭제 (Erase)	2 ms	읽기의 약 80배, 쓰기의 약 9배 느림

비대칭성 주목: 읽기는 매우 빠르지만, 쓰기는 읽기보다 훨씬 느리고, 삭제는 쓰기보다도 훨씬 느리다. 이 비대칭성이 FTL 설계의 핵심 동기가 된다. HDD에서는 읽기와 쓰기의 속도가 거의 같았지만, 플래시에서는 완전히 다르다.

Erase-Before-Write — 쓰기 전 삭제 의무

플래시 메모리의 가장 중요한 제약 조건이다.

규칙: 이미 데이터가 쓰여진 메모리 영역에 다시 쓰려면(overwrite), 반드시 먼저 삭제(erase)해야 한다.

왜 그런가?: 플래시 메모리의 물리적 특성 때문이다. 플래시 셀은 Floating Gate에 전자를 가두는 방식으로 데이터를 저장한다. 쓰기(Program) 연산은 전자를 주입하여 비트를 1에서 0으로만 바꿀 수 있다. 0을 다시 1로 되돌리려면 블록 전체에 강한 전압을 걸어 전자를 모두 빼내는 삭제(Erase) 연산이 필수적이다.

문제점: 페이지 하나만 덮어쓰고 싶어도, 그 페이지가 속한 블록 전체를 지워야 한다. 블록 안의 다른 유효한 페이지들까지 날아가므로, 먼저 유효한 데이터를 다른 곳에 복사해둬야 한다. 이 과정이 매우 느리다.

블록 k (128KB, 32 페이지)
+------+------+------+------+------+------+
| P0   | P1   | P2   | ...  | P30  | P31  |  <-- 모두 유효한 데이터
+------+------+------+------+------+------+

P0을 덮어쓰고 싶다면?

Step 1: 블록 k 전체 삭제 (2ms)
+------+------+------+------+------+------+
| free | free | free | ...  | free | free |  <-- 모든 데이터 사라짐!
+------+------+------+------+------+------+

Step 2: P0에 새 데이터 쓰기 + P1~P31은 원래 데이터 복원
+------+------+------+------+------+------+
| NEW  | P1   | P2   | ...  | P30  | P31  |  <-- 31개 페이지를 불필요하게 재기록
+------+------+------+------+------+------+

이 방식은 너무 비효율적이므로, 실제로는 Out-of-place Write(다른 빈 페이지에 새 데이터를 쓰고, 원본은 무효화)를 사용한다. 이것이 FTL의 핵심 아이디어다.

Lifetime Limitation — 수명 제한

플래시 메모리 셀은 삭제 횟수에 한계가 있다.

블록당 약 100,000회 삭제 가능
이 횟수를 초과하면 셀이 전자를 안정적으로 보관하지 못해 데이터 손상 발생

왜 중요한가?: 특정 블록만 집중적으로 삭제하면 그 블록이 먼저 수명을 다한다. 따라서 Wear Leveling(마모 균등화) — 삭제를 모든 블록에 골고루 분산시키는 기법 — 이 SSD의 FTL에서 필수적이다.

Flash File System Architecture — 플래시 파일 시스템 아키텍처

핵심 고려사항: 호환성

기존의 파일 시스템(ext4, NTFS 등)은 HDD를 기준으로 설계되었다. 파일 시스템은 "섹터 번호"로 디스크에 읽기/쓰기를 요청한다. 플래시 메모리를 기존 파일 시스템과 함께 쓰려면, 플래시 드라이버가 디스크 드라이버와 동일한 인터페이스를 제공해야 한다.

소프트웨어 스택 비교

[HDD 경로]                          [Flash 경로]
System Call Interface               System Call Interface
        |                                   |
   File System                         File System
        |                                   |
  Buffer Cache (메모리)               Buffer Cache (메모리)
        |                                   |
  Sector Number                       Sector Number
        |                                   |
   Disk Driver                           FTL
        |                           (Flash Translation Layer)
       HDD                                 |
                                    Flash Memory Driver
                                            |
                                      Flash Memory

차이점: HDD 경로에서는 "섹터 번호 = 물리적 디스크 위치"가 고정적이다. 플래시 경로에서는 FTL이 중간에 끼어서 "섹터 번호 -> 플래시 페이지 번호"를 동적으로 매핑한다.

Flash Translation Layer (FTL) — 플래시 변환 계층

FTL은 플래시 메모리 스토리지 시스템의 두뇌이다. (Flash memory안에 저장되어 있음)

역할:
1. 섹터-페이지 매핑: 파일 시스템이 요청하는 논리적 섹터 번호를 플래시 메모리의 물리적 페이지 번호로 변환
2. 상위 계층 호환성 보장: 상위 계층에는 디스크 드라이버와 동일한 Read Sectors / Write Sectors 인터페이스를 제공

왜 FTL이 필요한가?: 플래시 메모리는 HDD와 달리 erase-before-write 제약, out-of-place write, wear leveling 등의 특수한 관리가 필요하다. 이런 복잡성을 FTL이 모두 흡수하여, 상위 계층(파일 시스템)은 마치 HDD에 쓰는 것처럼 동작할 수 있다.

FTL이 없으면?: 파일 시스템이 Flash Memory에 직접 Read/Write/Erase 세 가지 연산을 보내야 한다. 기존 파일 시스템(Read Sectors, Write Sectors만 지원)과 플래시 메모리(Read, Write, Erase 필요) 사이에 인터페이스 불일치(Mismatch)가 발생한다. FTL이 이 불일치를 해소한다.

FTL이 없는 경우 (Mismatch!):

  File System
  Read Sectors / Write Sectors
        |
    Mismatch!  <-- 파일 시스템은 Erase를 모름
        |
  Read / Write / Erase
  Flash Memory

FTL이 있는 경우 (해결):

  File System
  Read Sectors / Write Sectors     <-- HDD와 동일한 인터페이스
        |
      FTL                          <-- 매핑 + erase 관리
        |
  Device Driver
        |
  Flash Memory

Overwriting Pages — 페이지 덮어쓰기 문제

직접 덮어쓰기의 비용

앞서 설명한 erase-before-write를 실제 예시로 보자.

블록 k에 32개 페이지(P0~P31)가 있고, P0만 덮어쓰고 싶은 상황:

[원본] Block k:
| P0(valid) | P1(valid) | P2(valid) | ... | P31(valid) |

[Step 1] Block k 전체 삭제 (2ms):
| free      | free      | free      | ... | free       |

[Step 2] P0에 새 데이터 쓰기 + P1~P31 복원:
| NEW DATA  | P1(valid) | P2(valid) | ... | P31(valid) |

문제: 페이지 하나를 바꾸려고 블록 전체를 삭제하고 31개의 변하지 않은 페이지까지 다시 써야 한다. 이것은 erase-before-write 연산이 매우 느린 이유이다. 이 문제를 해결하기 위해 LFS와 Out-of-place Write 기법이 등장한다.

Log-structured File System (LFS) — 로그 구조 파일 시스템

기본 원리

LFS는 HDD 시절에 이미 존재하던 아이디어로, 플래시 메모리의 out-of-place write와 매우 잘 어울린다.

쓰기 연산: LFS는 파일 데이터와 메타데이터(inode 등)를 모아서 큰 로그(Log)로 만들고, 이 로그를 세그먼트(Segment)라는 큰 빈 공간에 단일 디스크 I/O로 한꺼번에 기록한다.

File Cache (메모리)
+-+-+-+-+-+-+
|D|D|C|D|C|D|   D = dirty page (변경됨)
|C|D|D|C|D|C|   C = clean page (변경 안됨)
+-+-+-+-+-+-+
        |
        | dirty 페이지들만 수집
        v
+---------------------------------------------+
| File data + Meta data                        |  <-- Dedicated memory (로그 버퍼)
+---------------------------------------------+
        |
        | 단일 디스크 I/O로 기록
        v
Disk (로그):
+----------+---+---+---+---+---+---+---+---+----------+
| Segment 0|   |   |   |   |   |   |   |   | Segment N|
| (사용중)  |   |   |   |   |   |   |   |   | (비어있음)|
+----------+---+---+---+---+---+---+---+---+----------+
                     ^
                     |
           +--+-----+-----+------+------+---+-----+-------+
           |data|Inode|Dir |Inode| data |Inode|Dir |Inode  | Inode Map | Summary Block
           |file2|file2|dir2|dir2|file1|file1|dir1|dir1   | 
           +-----+-----+----+-----+------+------+----+------+

세그먼트 내부 구조: 하나의 세그먼트에는 여러 파일의 데이터 블록, inode, 디렉터리 엔트리가 섞여 들어가고, 맨 끝에 Inode Map과 Summary Block이 붙는다.

Inode Map

LFS에서 file1의 데이터를 수정하면, 새 데이터 블로과 함께 file1의 inode도 새 위치에 다시 기록된다. file1의 inode번호는 알지만 disk에 어디있는지 모름

LFS:
inode 5번 -> 처음엔 세그먼트 0의 오프셋 200에 기록
-> 수정 후 세그먼트 3의 오프셋 800으로 이동
-> 또 수정 후 세그먼트 7의 오프셋 150으로 이동
-> 지금 어디...?

Inode Map은 inode 번호 -> 해당 inode의 현재 디스크 주소 매핑 테이블이다.

Inode Map:
+----------+---------------------------+
| inode 번호 | 현재 디스크 위치 (세그먼트, 오프셋) |
+----------+---------------------------+
|    1     | Segment 3, offset 500     |
|    2     | Segment 3, offset 600     |
|    5     | Segment 7, offset 150     |
|   ...    | ...                       |
+----------+---------------------------+

Summary block

Garbage Collection(GC) 시점에, 특정 세그먼트를 정리하려면 그 안의 각 데이터 블록이 아직 유효한지 무효한지 판별해야 한다. 유효한 블록은 다른 곳으로 복사하고, 무효한 블록은 버린다. 그런데 데이터 블록만 봐서는 "이 블록이 어떤 파일의 몇 번째 블록인지" 알 수 없다.

Summary Block (세그먼트 끝에 위치):
+-------+--------------+-----------+
| 오프셋 | inode 번호    | 블록 번호   |
+-------+--------------+-----------+
|   0   | inode 5 (file2) | block 0 |
|   1   | inode 5 (file2) | inode   |
|   2   | inode 8 (dir2)  | block 0 |
|   3   | inode 8 (dir2)  | inode   |
|   4   | inode 3 (file1) | block 0 |
|   5   | inode 3 (file1) | inode   |
|   6   | inode 7 (dir1)  | block 0 |
|   7   | inode 7 (dir1)  | inode   |
+-------+--------------+-----------+

세그먼트 X (GC 대상):
+--------+--------+--------+--------+
| offset0| offset1| offset2| offset3|
| file2  | file2  | file1  | file1  |
| data   | inode  | data   | inode  |
+--------+--------+--------+--------+

Summary: offset0 = inode5/block0, offset2 = inode3/block0

[판별]
- offset0 (inode5/block0): Inode Map -> inode5 조회 -> block0 포인터가 
  이미 다른 세그먼트를 가리킴 -> 무효! (나중에 file2가 수정되어 새 위치에 쓰였음)
  
- offset2 (inode3/block0): Inode Map -> inode3 조회 -> block0 포인터가 
  아직 이 세그먼트의 offset2를 가리킴 -> 유효! -> 복사 필요

Checkpoint Region (CR)

디스크의 맨 앞 고정 위치 에 아주 작은 영역을 하나 잡아두는데, 이걸 CR이라고 한다.

디스크 전체 레이아웃:
+----+--------------------------------------------------+
| CR | Segment 0 | Segment 1 | Segment 2 | ...          |
+----+--------------------------------------------------+
  ^
  |
  항상 고정된 위치 (디스크 맨 앞)

가장 최신 Inode Map(또는 최신 segment)의 disk 주소를 저장

CR은 고정위치인가?

최소한 하나의 진업점(anchor)은 고정된 위치에 있어야함

전통 FS:  Superblock(고정) -> Inode List(고정) -> 데이터
LFS:      CR(고정) -> Inode Map(이동) -> Inode(이동) -> 데이터(이동)

정리

Inode와 summary blcok은 둘 다 segment 끝에 붙는다
둘 다 매 segment마다 기록된다.

Segment 0:
+------+-------+------+-------+-----------+---------+
| data | inode | dir  | inode | Inode Map | Summary |
| file2| file2 | dir2 | dir2  |    v1     | Block   |
+------+-------+------+-------+-----------+---------+

Segment 1:
+------+-------+------+-------+-----------+---------+
| data | inode | data | inode | Inode Map | Summary |
| file5| file5 | file3| file3 |    v2     | Block   |
+------+-------+------+-------+-----------+---------+

Segment 2:
+------+-------+-----------+---------+
| data | inode | Inode Map | Summary |
| file1| file1 |    v3     | Block   |
+------+-------+-----------+---------+

Summary Block: 각 세그먼트의 것이 독립적으로 의미가 있어. Segment 0의 Summary는 Segment 0 안의 블록 정보만 담고, Segment 1의 Summary는 Segment 1 안의 블록 정보만 담아. GC가 특정 세그먼트를 정리할 때 그 세그먼트의 Summary만 읽으면 돼.
Inode Map: 매번 세그먼트에 기록되지만, 가장 최신 버전만 유효해. v1, v2, v3 중에서 v3만 현재 전체 파일 시스템의 inode 위치를 정확히 반영하고, v1과 v2는 과거 스냅샷이라 쓸모없어.

LFS의 Garbage Collection — 가비지 컬렉션

LFS는 항상 새로운 빈 세그먼트에 쓰므로, 시간이 지나면 빈 세그먼트가 부족해진다. 이때 Garbage Collection(GC)이 필요하다.

과정:

[1단계] 메모리에서 F1, F3, F5, F6 파일 수정

[2단계] 수정된 파일들을 새 빈 세그먼트(Segment 1)에 기록
        이전 세그먼트(Segment 0)의 원본은 무효화(invalidate)

Disk:
+----------+----------+----------+----------+
| Seg 0    | Seg 1    | Seg 2    | Seg 3    |
| F1 F2    | F1'F3'   | (free)   | (free)   |
| F3 F4    | F5'F6'   |          |          |
| (일부무효)| (유효)   |          |          |
+----------+----------+----------+----------+
 ^F1,F3 무효          

[3단계] 계속 쓰다가 빈 세그먼트가 없어짐 -> Oops!

[4단계] Garbage Collection 수행
        - 무효 데이터가 많은 세그먼트를 선택
        - 유효 데이터만 다른 곳으로 복사
        - 해당 세그먼트를 비움

        ==> Very large overhead! (유효 데이터 복사 비용)

GC의 오버헤드: 유효한 데이터를 읽어서 다른 세그먼트로 복사하고, 원래 세그먼트를 비우는 과정이 매우 비싸다. 특히 플래시에서는 복사 = 읽기 + 쓰기 + (결국 삭제)이므로 HDD보다 더 큰 부담이 된다.

Flash 쓰기 방식 비교

Block-level Writes — 블록 단위 쓰기

동작 방식: 페이지가 변경되면, 해당 페이지가 속한 블록 전체를 새로운 빈 블록으로 복사한다.

Flash Memory:
Block 0: | F1 | F2 | F3 | F4 |    <-- F1을 수정하고 싶음

(a) F1 덮어쓰기:
Block 0: | F1 | F2 | F3 | F4 |    <-- 무효화
Block 1: | F1'| F2 | F3 | F4 |    <-- 블록 전체를 새 블록에 복사 + F1만 갱신

(b) 이어서 F3 덮어쓰기:
Block 1: | F1'| F2 | F3 | F4 |    <-- 무효화
Block 2: | F1'| F2 | F3'| F4 |    <-- 또 블록 전체 복사!

장점: 구현이 단순하다. 블록 단위로 통째로 복사하면 된다.

단점: 변하지 않은 페이지(F2, F3/F4 등)까지 불필요하게 복사된다. 쓰기 성능이 매우 나쁘다 (Write Amplification이 크다).

Scheme 2: Page-level Writes — 페이지 단위 쓰기 (Out-of-place Write)

동작 방식: 변경된 페이지만 새로운 빈 페이지에 쓰고, 원래 페이지를 무효화한다. 블록 전체를 복사하지 않는다.

Flash Memory:
Block 0: | F1 | F2 | F3 | F4 |    <-- F1을 수정하고 싶음

(a) F1 덮어쓰기:
Block 0: | X  | F2 | F3 | F4 |    <-- F1 자리만 무효화 (X 표시)
Block 1: | F1'|    |    |    |    <-- F1'만 새 빈 페이지에 쓰기

(b) 이어서 F3 덮어쓰기:
Block 0: | X  | F2 | X  | F4 |    <-- F3 자리도 무효화
Block 1: | F1'| F3'|    |    |    <-- F3'만 새 빈 페이지에 쓰기

장점: 변경된 페이지만 쓰므로 쓰기 성능이 좋다. Write Amplification이 최소화된다.

단점: FTL 테이블이 매우 커진다. 블록 단위가 아닌 페이지 단위로 매핑을 관리해야 하므로, 섹터 수만큼의 엔트리가 필요하다.

두 방식 비교

비교 항목	Block-level Write	Page-level Write
복사 단위	블록 전체 (변경 안 된 페이지 포함)	변경된 페이지만
쓰기 성능	나쁨 (불필요한 복사 많음)	좋음
FTL 테이블 크기	작음 (블록 수만큼)	큼 (페이지 수만큼)
Write Amplification	높음	낮음

Page-mapping FTL — 페이지 매핑 FTL

구조

Page-mapping FTL은 섹터 번호 -> 물리적 페이지 번호 매핑 테이블을 유지한다.

Page-mapping FTL Table:
+-----------+----------+
| Sector No | Page No  |
+-----------+----------+
|     4     |    0     |
|     5     |    1     |
|     6     |    2     |
|    10     |    3     |
|   ...     |   ...    |
+-----------+----------+

Read 동작 — 섹터 10 읽기

FTL 테이블에서 섹터 10을 찾음 -> 페이지 3에 매핑됨
플래시 메모리의 페이지 3에서 데이터를 읽음

Read Sector 10:
  FTL Table: Sector 10 -> Page 3
  
  NAND Flash:
  Block 0: | P0(S4) | P1(S5) | P2(S6) | P3(S10) |  <-- P3에서 읽기
  Block 1: | P4     | P5     | P6     | P7      |

Write 동작 — 섹터 10 쓰기 (Out-of-place Write)

새로운 빈 페이지(예: 페이지 4)에 수정된 데이터를 쓴다
FTL 테이블에서 섹터 10의 매핑을 페이지 3 -> 페이지 4로 갱신한다
기존 페이지 3을 무효(invalid)로 표시한다

Write Sector 10 (수정된 데이터):

  [Before]                              [After]
  FTL: Sector 10 -> Page 3              FTL: Sector 10 -> Page 4 (갱신!)

  Block 0:                              Block 0:
  | P0(S4) | P1(S5) | P2(S6) | P3(S10)|  | P0(S4) | P1(S5) | P2(S6) | X(무효)|
                                        
  Block 1:                              Block 1:
  | P4     | P5     | P6     | P7     |  | P4(S10)| P5     | P6     | P7     |
                                           ^ 새 데이터가 여기에 기록됨

Out-of-place Write의 핵심: 데이터를 원래 위치(in-place)에 덮어쓰지 않고, 다른 빈 위치(out-of-place)에 쓴다. 그리고 FTL 매핑 테이블만 갱신한다. 이렇게 하면 erase-before-write를 피할 수 있다 (즉시는).

나중에는 어떻게?: 무효화된 페이지가 쌓이면, 결국 빈 블록이 부족해진다. 이때 Garbage Collection이 동작하여 무효 페이지를 정리하고 블록을 삭제하여 빈 블록을 확보한다.

SSD 소개 — Solid-State Device

SSD란?

SSD(Solid-State Device)는 플래시 메모리를 저장 매체로 사용하는 스토리지 장치이다. HDD처럼 회전하는 디스크나 움직이는 헤드가 없다.

SSD의 장점

장점	설명
뛰어난 읽기 지연 시간	HDD 대비 수백~수천 배 빠른 랜덤 읽기
높은 순차 대역폭	순차적 읽기/쓰기 속도가 매우 높음
낮은 전력 소비	모터/액추에이터가 없으므로 전력 효율적
물리적 움직임 없음	충격에 강하고, 소음 없음, 발열 적음
GB당 가격 하락 추세	점점 HDD와 가격 격차가 줄어듬

SSD의 단점 (Surprise!)

단점	설명
랜덤 쓰기가 느릴 수 있음	erase-before-write 제약, GC 오버헤드
플래시 블록의 마모	삭제 횟수 한계 (100,000회), 수명 제한

핵심 포인트: SSD는 읽기는 압도적으로 빠르지만, 쓰기(특히 랜덤 쓰기)는 GC가 발생하면 HDD보다 느려질 수도 있다. "SSD가 모든 스토리지 문제를 해결하나?"라는 질문에 대한 답은 "아직 아니다"이다.

SSD Structure — SSD 내부 구조

구성 요소

SSD 내부는 사실상 작은 컴퓨터이다. 단순한 저장장치가 아니라, 프로세서와 메모리를 갖춘 독립적인 시스템이다.

+---------------------------------------------------------------+
|                         SSD 내부                                |
|                                                               |
|  +----------+     +------+     +-----------+                  |
|  | Processor|     | SRAM |     |           |                  |
|  +----+-----+     +--+---+     |  Low-level|                  |
|       |              |         |  Flash    |    Flash Bus     |
|  =====+==============+=Control=| Controller|=======+========  |
|       |                        |           |       |          |
|  +----+------+                 +-----------+  +----+----+    |
|  |   Host    |    Data Bus                    | Flash   |    |
|  | Interface |<============>DRAM<============>| Package |x4  |
|  +----+------+                                +---------+    |
|       |                                                       |
+-------+-------------------------------------------------------+
        |
   PCI or SATA
   (6Gbps, ~700MB/sec)

구성 요소	역할
Host Interface	호스트(CPU)와 SSD를 연결. PCI Express 또는 SATA 인터페이스 사용 (최대 6Gbps, ~700MB/sec)
Processor	SSD 내부의 CPU. FTL 알고리즘, GC, Wear Leveling 등을 실행
SRAM	프로세서의 고속 캐시/작업 메모리
DRAM	FTL 매핑 테이블을 캐싱하는 대용량 메모리. Host Interface와 Flash Controller 사이의 데이터 버퍼 역할도 수행
Low-level Flash Controller	플래시 패키지에 실제 Read/Write/Erase 명령을 내리는 하드웨어
Flash Package	실제 NAND 플래시 메모리 칩. 보통 여러 개가 병렬로 연결
Flash Bus	Flash Controller와 Flash Package를 연결. 패키지당 ~40MB/sec

데이터 흐름: Host -> Host Interface -> DRAM(버퍼) -> Flash Controller -> Flash Package

병렬성: 여러 Flash Package가 별도의 Flash Bus로 연결되어 동시에 데이터를 주고받을 수 있다. 예를 들어 4개 패키지가 각각 40MB/sec이면 총 160MB/sec의 대역폭을 달성할 수 있다.

Flash Package 내부 구조 — 계층적 구성

계층 구조 (작은 것 -> 큰 것)

하나의 Flash Package 내부는 다음과 같은 계층으로 구성된다:

Page (4KB)  -- 여러 개 -->  Block (256KB, 64 pages)
Block       -- 여러 개 -->  Plane (512MB, 2048 blocks + Register)
Plane       -- 4개    -->  Die (2GB, 4 planes)
Die         -- 2개    -->  Package (4GB, 2 dies)

각 계층 상세

Page — 최소 접근 단위

크기: 4KB (강의 초반의 512B는 구형 사양)
읽기/쓰기의 최소 단위

Block — 최소 삭제 단위

크기: 256KB
구성: 64개의 페이지
삭제(Erase)는 블록 단위로만 가능

Plane — 블록들의 집합 + Register

크기: 512MB
구성: 2048개의 블록 + 페이지 크기의 레지스터(REG)
레지스터(REG)의 역할: 플래시 셀 배열(NAND array)과 외부 I/O 버스 사이의 중간 버퍼이다.
- 읽기 시: 먼저 페이지 데이터를 셀 배열 -> 레지스터로 전송 (25us), 그 다음 레지스터 -> 버스로 직렬 전송 (20us)
- 쓰기 시: 먼저 버스 -> 레지스터로 데이터 수신, 그 다음 레지스터 -> 셀 배열로 프로그래밍 (200us)
같은 Die 내의 서로 다른 Plane은 동시에 동작 가능 (Multi-plane operation)

Die — Plane들의 집합

크기: 2GB
구성: 4개의 Plane
Die는 독립적인 실행 유닛이다. 서로 다른 Die는 동시에 명령을 처리할 수 있다.

Package — Die들의 집합

크기: 4GB
구성: 2개의 Die
하나의 8-bit Serial I/O Bus로 SSD 컨트롤러에 연결
버스 대역폭: ~40MB/sec

접근 시간 정리

연산	시간	설명
Page Read to Register	25 us	NAND 셀 배열 -> Plane 내부 레지스터로 페이지 전송
Page Program from Register	200 us	레지스터 -> NAND 셀 배열로 프로그래밍 (쓰기)
Serial Access to Register	20 us	레지스터 <-> I/O 버스 간 데이터 직렬 전송
Block Erase	1.5 ms	블록 전체 삭제

읽기의 전체 시간: Page Read to Register (25us) + Serial Access to Register (20us) = 약 45us

쓰기의 전체 시간: Serial Access to Register (20us) + Page Program from Register (200us) = 약 220us

4GB Package 용량 검증

Page:   4KB
Block:  64 pages x 4KB = 256KB
Plane:  2048 blocks x 256KB = 512MB
Die:    4 planes x 512MB = 2GB
Package: 2 dies x 2GB = 4GB  (검증 완료)

핵심 개념 정리 (시험 대비)

전체 관계도

호스트 (파일 시스템)
  | "섹터 n번 읽어줘 / 써줘"
  v
FTL (Flash Translation Layer)
  | 섹터 n -> 페이지 p 매핑 조회/갱신
  | Out-of-place Write 수행
  | Garbage Collection 수행
  | Wear Leveling 수행
  v
Flash Controller
  | 물리적 Read/Write(Program)/Erase 명령
  v
Flash Package
  | Package > Die > Plane > Block > Page
  v
NAND 셀 배열 (Floating Gate에 전자 저장)

빈출 키워드 요약

키워드	한 줄 정의
Page	읽기/쓰기의 최소 단위 (4KB)
Block	삭제의 최소 단위 (256KB = 64 pages)
Erase-Before-Write	이미 쓰여진 영역에 다시 쓰려면 반드시 먼저 삭제해야 하는 제약
Out-of-place Write	원래 위치가 아닌 새 빈 위치에 쓰고, FTL 매핑만 갱신하는 기법
FTL (Flash Translation Layer)	논리 섹터 번호 -> 물리 페이지 번호 매핑을 관리하는 계층
Page-mapping FTL	섹터마다 개별 페이지 매핑. 성능 좋으나 테이블 큼
Block-level Write	블록 전체를 복사하는 방식. 구현 단순하나 성능 나쁨
Page-level Write	변경된 페이지만 이동하는 방식. 성능 좋으나 FTL 테이블 큼
Garbage Collection (GC)	무효 페이지를 정리하고 빈 블록을 확보하는 작업
Wear Leveling	삭제를 모든 블록에 균등하게 분산시켜 수명을 연장하는 기법
Lifetime Limitation	블록당 ~100,000회 삭제 제한
LFS (Log-structured File System)	변경 데이터를 로그 형태로 빈 세그먼트에 순차 기록하는 파일 시스템
Write Amplification	실제 쓰려는 양보다 더 많은 물리적 쓰기가 발생하는 현상
Plane	2048 블록 + 레지스터로 구성된 단위 (512MB)
Die	4개의 Plane으로 구성된 독립적 실행 유닛 (2GB)
Package	2개의 Die로 구성된 물리적 칩 (4GB)
Register (REG)	Plane 내부의 페이지 크기 버퍼. NAND 셀과 I/O 버스 사이 중간 단계

HDD vs SSD 핵심 비교

비교 항목	HDD	SSD (Flash)
저장 매체	자기 디스크 (platter)	NAND 플래시 셀
동작 부품	있음 (모터, 헤드)	없음 (Solid-State)
랜덤 읽기	느림 (seek + rotation)	매우 빠름 (~25us)
순차 쓰기	비교적 빠름	빠름
랜덤 쓰기	느림	GC 시 매우 느릴 수 있음
덮어쓰기	제자리 가능 (in-place)	불가 (erase-before-write)
수명 제한	기계적 마모	삭제 횟수 제한 (전기적 마모)
주소 변환	불필요 (CHS/LBA 고정)	FTL 필수
소비 전력	높음	낮음

Kamator0

이전 포스트

I/O Systems

다음 포스트