Computer Science

SSD SW 개발 이론 기초

SSD와 연관된 소프트웨어 개발을 위해 알아야할 지식을 간략하게 정리해보았다.

Sungjun Park

2024년 9월 10일 — 29 min read

Photo by Samsung Memory / Unsplash

해당 글은 여러 좋은 글을 바탕으로 스스로 머리속에 정리하기 위해 작성된 게시물입니다. 아래 참고 문서를 직접 살펴보시는 것이 더 좋습니다 😄

SSD 의 특성

필연적으로 HDD 와 비교하게 된다. HDD 의 경우 기계적 장치를 통해서 저장장치가 구현되어있다. HDD의 구조를 떠올려보면 여러 겹의 자기 플래터를 회전시키며 플래터에 기록된 정보를 조회하는 방식을 사용한다. 이러한 이유로 인해 HDD는 기계적 회전 속도의 영향 그리고 저장 순서 등이 R/W 에 대한 성능적 문제를 야기하며, 기계적 동작에 의한 failure 또한 고려해야한다.
SSD 의 경우 NAND Flash Memory 를 통해서 저장장치를 구현한다. 이는 전자적 장치로 Floating gate 트랜지스터에 에 전압을 인가하면서 비트의 셀의 비트를 쓰고 읽는다. 이 덕분에 HDD 에서 필요한 seek time (~10ms) 이 필요하지 않다. 또한 SSD의 경우 interleaving 을 통해 병렬적으로 데이터를 읽고 쓸 수 있어 월등히 뛰어난 조회 및 쓰기 속도를 보장한다.

하지만, SSD 에게도 여전히 핸디캡은 존재한다. Flash memory 의 경우 Bit 를 트랜지스터에 쓰고 지우는 과정 (P/E Cycle, Program/Erase) 에서 일부 전자가 오류로 인해 트랜지스터에 갇히는 현상이 있다. 이렇게 트랜지스터에 갇히는 전자가 증가하게 되면 결과적으로 해당 셀은 더 이상 사용할 수 없게 된다. (최대 P/E Cycle 을 초과하는 경우 사용 불가한 셀로 취급한다.) 이로 인해서 SSD 의 수명은 제한적이다. (Wearing-off)
- 따라서 SSD를 적절하게 제어하기 위해서는 각 셀의 P/E Cycle 을 균등하게 분배하는 것이 아주 중요하다.
  - 이러한 행위를 wear-leveling 이라고 한다.

또한 특이한 특징이 있는데, NAND Flash 에서 데이터에 엑세스하면서 주변의 PAGE 의 bit 를 flip 시키는 경우가 존재한다. 이를 READ/WRITE DISTURUBS 라고 한다. 이는 신뢰성 / 안정성에 영향을 미치는 요소로 작용한다.
- -> wearing off 보다는 덜 중요한 문제

최대 P/E Cycle 의 경우 SLC / MLC / TLC / QLC 이냐에 따라서 각각 다르다. 한 셀에 몇 비트를 저장할 수 있느냐에 따라 셀을 분류하는데, 1bit 를 저장할 수 있는 셀을 SLC, 2bit -> MLC, 3bit -> TLC, 4bit->QLC 순이다. 한 셀에 더 많은 비트를 저장할 수 있으므로 제조 단가는 내려가나 P/E Cycle 는 저하된다.
- 부가적으로, MLC, TLC 와 같이 한 셀에서 여러 비트를 표현할 수 있는 것은 한 셀에 채워진 전자의 양을 기준으로 여러 비트를 표현할 수 있기 때문이다. 앞서 설명한 Wearing off 와 겹쳐서 생각해보면, P/E Cycle 이 왜 감소하는지 알 수 있을 것이다.
  - https://cappleblog.tistory.com/582 <- 여기 잘 설명되어있음.
SSD Benchmark
- SSD 의 성능의 척도를 평가하기 위해서 여러가지 요소가 고려된다. 대표적으로 P/E Cycle, R/P/E latency, Throughput, IOPS 등이 있다. 아래 자료와 함께 해당 내용에 대해서 잘 설명하는 글을 읽어보자.

SSD 의 구조

위 그림들에 나타난 것처럼, SSD 내에서 데이터는 PLANE BLOCK PAGE 단위로 Grouping 된다.
- Flash 안에는 여러 개의 plane 으로 구성되며, Plane 내에는 여러개의 Block 으로 구성되고, 다시 Block 내에는 여러 Page 로 구성된다.
  - Page size 의 경우 2~16KB 정도로 구성된다.
SSD 의 아키텍처를 잠시 살펴보면 다음과 같다.
- Host 의 요청은 SATA / PCIe 와 같은 Host Interface 를 통해 전달된다.
- SSD는 자체적으로 DRAM 을 가지고 있고 이곳에서는 후술될 Address Mapping, Cache 역할을 수행한다. (요즘은 DRAM을 탑재하지 않은 경우도 꽤 있다.)

SSD 의 기본 동작

READ

읽기는 페이지 사이즈 단위로 실행 (Reads are aligned on page size)

데이터를 읽을 때 1 바이트를 요청하더라도 해당 바이트가 속한 페이지 전체를 불러온다.

PROGRAM (WRITE)

쓰기는 페이지 사이즈 단위로 실행(Writes are aligned on page size)

쓰기를 실행할 때도 마찬가지로 페이지 단위로 실행한다. 그래서 한 바이트를 기록하는 경우에도 전체 페이지를 기록해야한다. 이렇게 필요 이상의 쓰기가 발생하는 것을 Write Amplification 이라고 한다. SSD 에서는 페이지를 쓰는 것을 Write 대신 Program 이라는 용어를 활용하곤한다.
- Throughput 을 최대화하기 위해서 작은 쓰기를 버퍼링하고 버퍼가 가득차면 단일 쓰기로 최대한 많은 데이터를 기록하는 방법을 사용할 수 있다.

ERASE

삭제는 블록 사이즈 단위로 실행 (Erases are aligned on block size)

페이지는 덮어쓰기가 불가능하기 때문에 한번 "stale" 상태로 된 페이지는 반드시 ERASE 작업을 거쳐서 "free" 상태로 전이할 수 있다. 그러나 삭제 작업은 단일 페이지 단위가 아닌 블록 단위로 이루어진다. (stale 상태의 페이지가 속한 블록을 통채로 free 시켜야함.)
ERASE 명령은 SSD Controller 가 Free 공간이 필요할 때 자동적으로 내부 명령을 실행해서 Garbage collection 을 실행할 때 사용된다.

Overwrite

페이지는 덮어 쓰기 할 수 없다. (Pages are not be overwritten)

NAND Flash Memory 페이지는 반드시 "free" 상태일 때만 쓰기를 할 수 있다. 데이터가 변경되면 페이지의 내용은 내부 레지스터로 복사된 후 레지스터에서 변경되어 새로운 "free" 상태의 페이지로 기록된다. 이를 "READ-MODIFY-WRITE" 라고 한다.
SSD 에서 데이터는 다른 페이지로 이동하지 않고는 (in-place-update) 변경될 수 없다. 이렇게 변경된 데이터가 새로운 페이지에 완전히 기록되면 해당 원본 페이지는 "stale" (dirty 상태 비슷...) 로 마킹되고 ERASE 되기 전까지 해당 상태로 유지된다.

Write amplification

Flash memory 에서 Write 행위는 반드시 free page 에 기록해야하며, 한 번에 page 단위로 align 되어 기록할 수 있다. 이러한 SSD의 특성으로 인해서 실제 Host 에서 write 를 요청한 byte 양보다 실제로 flash 에서 write 하는 양의 차이가 발생한다. 이에 관한 지표가 Write Amplification Factor 이다.

WAF(Write Amplication Factor
- (Bytes written from Flash == Byte written from Host + Bytes written during GC) / Bytes Written from Host
- 일반적으로 WAF 값은 >= 1 이다.
- WAF 값이 낮을 수록 GC의 효율이 좋음을 나타낸다.

FTL

FTL 의 역할

Interface Adaptor
Bad Block Management
Logical Block Mapping
Wear-leveling
Garbage Collection
Write Amplification

FTL 의 Layer

Sector translation layer
- Address mapping
- Garbage collection
- Wear leveling
Block Management layer
- Bad block management
- Error handling
Low level driver
- Flash interface

FTL 의 필요성

새로운 하드웨어 그리고 소프트웨어를 만들 때는 늘 "호환성"을 고려해야한다. 동일한 Interface 를 통해서 접근할 수 있어야 새로운 하드웨어를 차용하는데 어려움이 없다. Flash memory 또한 동일하며 이 때문에 HDD->SSD 전환이 빠르게 이루어질 수 있었다. SSD 또한 HDD / Tape 를 대상으로하는 host interface 와 동일한 interface 을 사용한다. 그러나, Flash Memory 의 경우 앞서 살펴본대로 HDD의 작동 방식과 다소 다르고, 특히 READ / PROGRAM / ERASE 를 기반으로 작동하며 HDD와는 다소 다르게 접근해야한다.
- 만약, 기존에 하던 방식대로 명령을 내리게 된다면 Flash Memory 기반에서는 제대로 작동하지 않을 것이다.
따라서, 메모리의 내부적인 특성을 숨기고 기존의 Interface 를 통해서 작동하도록하며, SSD 의 동작 방식에 적합하도록 제어하는 레이어가 별도로 필요하다. 그 역할을 하는 레이어가 바로 Flash Translation Layer 이다. FTL은 SSD Controller 내부에 위치하며 Garbage Collection / Logical Block Mapping 등의 역할을 수행한다.

Address Mapping

FTL의 주요 역할 중 하나는 Host 에서 바라보고 있는 논리 주소와 flash memory 에서의 실제 메모리의 주소를 매핑하는 것이다. Host 측에서는 논리 주소를 바탕으로 HDD에서의 동작과 동일하게 작동하며, FTL 에서 이 논리 주소를 실제 주소로 변환하여 Flash memory 에서 적합한 동작으로 변환한다.
가장 단순한 구현으로 Flash memory 에서 1:1로 address를 direct mapping 이 있는데, 해당 방법을 사용한다면 flash memory의 특성상 제대로된 효율을 얻을 수 없으며, wearing off 로 ssd의 수명이 급격하게 감소할 수 있다.
- page 1 에 데이터를 쓰고, 다시 overwrite 하는 예시가 대표적인 예시이다. 만약 Direct mapping 을 하게된다면 page 1 이 속한 block 을 erase 하고 다시 작성해야할 것이다. 이러한 행위는 다음과 같은 두 가지의 문제를 낳는다.
- Wearing off
  - 동일 block 에 대해서 P/E Cycle 을 과도하게 사용한다. 이는 결국 wearing off 로 이어지며, 해당 블록이 금새 사용 불가한 블록이 되어버린다.
- 느린 write
  - overwrite 과정에서 매번 P/E 를 수행해야하며 이는 WAF 가 증가하는 동시에 operation 자체가 증가한다. Erase 자체의 동작도 느린것도 덤이다.
이러한 이유로 Logical block 으로 실제 block 을 한 단계 추상화하며, 이를 mapping table 로 유지한다. Host 는 더 이상 물리적 주소를 바라보지 않고 논리적 주소를 바라본다. Mapping table 에는 각 물리적 주소를 연결하는 논리적 주소를 테이블로 유지하고, Host 에게는 논리적 주소를 노출하여 사용하도록 한다.
논리적으로 플래시 메모리의 주소를 매핑하는 방법은 여러가지가 있다.
- Page level mapping
  - 각 페이지에 대해서 논리적 페이지와 물리적 페이지를 매핑하는 방법이다. 아주 유연하지만 그 자체로 메타데이터를 표현하기 위해서 너무 많은 메모리를 사용해야한다.
- Block level mapping
  - 페이지 레벨의 매핑 테이블의 메모리 소모를 줄이기 위해서 블록 레벨로 매핑 테이블을 구성할 수 있다. Logical block number 와 함께 page offset 을 저장하여 사용하는 방식으로, Host 에서 page offset을 계산한다. 그러나, page offset의 경우 물리적 블록과 동일하게 유지되어야하여 논리적 페이지의 overwrite operation 에 대해서 블록 수준의 복사 작업이 빈번하게 일어날 수 있어 비효율적이다
- Hybrid
  - Page / Block level 의 매핑 각각의 장단점이 있으며 이를 잘 조율하는 것이 관건이다. 이러한 고민 속에 hybrid 방식이 등장하게 되었다. Hybrid 방식은 Page / Block level 단위의 매핑을 usage 에 따라 적절하게 혼합한 형태로 최근에 사용하고 있는 대부분의 SSD에서 적용되고 있다. 그 중 대표적인 방식이 Log structured 방식을 사용한 Log-block 매핑이다.

*A Reconfigurable FTL (Flash Translation Layer) Architecture for NAND Flash-Based Applications*

Log-block 방식은 LFS 의 방식과 유사한데, 유입되는 쓰기 동작은 시퀀셜하게 로그 블록에 기록되고 로그 블록이 꽉 채워지면 동일한 LBN(Logical Block Number)을 가지는 블록의 데이터와 병합하여 새로운 'free' 블록으로 기록하는 방법이다. log-block 자체는 몇 개만 유지되어 페이지 단위의 매핑은 아주 소량만 관리하면 된다.
- Log block 방식 내에서도 접근 방식이 세분화 된다. 아래 reference 에 있는 A Reconfigurable FTL (Flash Translation Layer) Architecture for NAND Flash-Based Applications 에서 각 접근방법을 간략하게 설명하고 있다.
- Log block 방식에서 눈여겨봐야할 것은 merge 가 얼마나 자주 일어나는가이다. merge 작업의 경우 다른 작업에 비해 비용이 크기에 해당 작업을 최소화하는 것이 중요하다. 이는 사용패턴 그리고 Mapping 의 구현 전략에 따라서 달라진다. (위에 언급한 논문에서는 이에 대한 전략과 그 해결 방법을 제안한다.)

이렇게 논리적인 매핑을 하게 될 때 Wear-leveling을 위해서 기존의 page 를 erase 하지 않고 invalid 처리 한 뒤 다른 page 에 기록하게 된다. 따라서 해당 invalid 상태의 page 를 수거하여 free block으로 전환시키는 과정이 필요한데, 이를 Garbage-collection 이라고 한다.

Garbage Collection

쓰기 작업 과정에서 Invalid page 가 발생한다. 해당 page 를 수거하지 않고 내버려둔다면 SSD 의 가용 용량은 점점 줄어들 것이다. 따라서 SSD 는 이러한 Page 들을 회수하기 위해서는 Garbage collection 을 주기적으로 실행해야한다.

Garbage Collection 의 과정은 간단하게 표현하면 다음과 같다.
- GC 대상 블록 선택
- GC 대상 블록의 Valid page 를 모두 복사
- GC 대상 블록을 Free block 처리
GC작업은 Background 에서 실행시키는 것이 유리하다.
- Garbage Collection 에서 해야하는 작업을 실제 쓰기 작업 중에 실행한다고 생각해보자. ERASE 동작의 경우 단순한 데이터 쓰기 동작(250 ~1500 us) 에 비해 (1500us ~ 3500us)로 많은 시간이 소요되어 쓰기 속도를 느리게 만드는 원인이 된다. 이러한 이유로 Background process 로 해당 작업을 실행시키는 것이 유리하다.
- 하지만 쓰기 부하가 큰 상황에서는 쓰기 요청에서 Garbage collection 이 필요한 경우가 있다. 이러한 경우 Forground 명령 실행에 방해될 수 있다. (이런 문제를 해결하기 위해서 Over-provisioning / Trim 등을 활용한다.)

Garbage Collection 을 하는 과정에서 블록의 이동이 발생하기에, 빈번하게 변경되는 데이터와 그렇지 않은 데이터 (Hot data / Cold data)를 구분하는 것도 중요하다. Hot data 와 cold data 가 함께 같은 위치에 존재한다면 hot-data 의 변경마다 cold -data 또한 함께 옮겨다녀야하며 이는 Write Amplication 이 점점 커지는 문제를 야기한다. (그러나 SSD Level 에서는 이를 예측할 수 없어 Application program level 에서 적절하게 분리하여 다뤄야한다.)

GC 대상 block 을 선정하는 과정에서는 해당 블록의 utilization 을 보고 선정한다. 물론 이 또한 여러 접근 방법이 있다.

Greedy
- utilization 값이 최소값이 되는 block 을 대상을 victim block 으로 선정하는 방법으로, 간단하게 구현할 수 있고 copying cost 가 가장 낮다.
- 그러나 wear leveling 이 고려되지 않았으며, 쓰기 지역성이 높을 때 제대로 동작하지 않는다.

Cost-Benefit
- 위 Benefit / Cost 값의 최대값을 기준으로 작동한다. 지역성이 높은 경우에도 잘 동작하여 wear leveling이 고려된 형식이다.
- 그러나, 이를 계산하기 위한 계산 및 데이터 오버헤드가 존재한다.

Over provisioning

Over-Provisioning 은 Host 에게 노출되는 논리적 블록의 수 보다 물리적 블록의 수를 더 많도록 해주는 것이다. 해당 공간은 펌웨어 이미지, FTL 메타데이터, Bad block 이 있는경우 활용, write buffer 등으로 활용한다. 그런데 눈여겨볼 것은 Over-provisioning 비율을 증가시키면 SSD의 성능이 향상된다는 것이다.

앞서 살펴본 FTL 의 동작을 살펴보면 Random write 부하가 큰 경우, stale 페이지를 Erase하기 전에 Free block 이 부족한 현상이 일어날 수 있다. 이런 경우 GC 프로세스는 쓰기 요청이 들어오면 동시에 Erase 를 실행해야하며 성능이 급격하게 감소하게 된다. Over-provisioning 은 이러한 높은 쓰기 부하 상황에서 buffer 역할을 수행한다.이러한 이유 때문에 일반적으로 7~25% 정도의 OP 공간을 잡아둔다.

TRIM

Host 입장에서는 지웠다고 생각하는 데이터가 SSD 에게는 그렇지 않을 수 있다. File system 상에서는 지웠다고 표시가 되어있지만, SSD 입장에서는 호스트로부터 삭제된 논리 블록의 주소를 알 수 없어 해당 블록은 사용중이라고 생각하게된다. 결국 Overwrite 가 발생할 때가 되어서야 stale page 임을 알게되고 write amplication 으로 이어지게 되어 성능의 하락을 초래한다.

이러한 문제를 해결하기 위해서 Host 에서 해당 논리 공간이 더 이상 필요하지 않다는 메시지를 SSD 로 전달할 수 있는데 그것이 바로 "TRIM" 명령어이다. 이는 OS / File System / SSD Controller 모두가 지원해야한다.

병렬 처리

물리적 한계로 인해서 NAND Flash 의 I/O 버스는 일정 대역폭 이상을 서비스할 수 없다. 따라서 성능을 향상시키기 위해서는 다수의 패키지에서 병렬로 처리하거나 interleaving mode 를 활용해야한다. SSD 에서는 다음과 같은 다양한 Level 에서의 병렬 처리 능력을 제공한다.

Channel-level parallelism. 플래시 컨트롤러는 여러 채널을 통해서 플래시 패키지와 통신한다. 이 채널들은 서로 독립적이며 동시에 액세스 가능하다. 각 개별 채널은 여러 패키지에 의해서 공유된다.
Package-level parallelism. 채널의 패키지들은 독립적으로 접근 가능하다. 동일 채널을 공유하는 패키지들은 인터리빙 모드로 동시에 명령 실행에 사용될 수 있다.
Chip-level parallelism. 패키지는 하나 또는 두개의 칩(Chips, 때로는 “dies”라고도 불림)을 가지며, 각 칩들은 독립적으로 병렬 접근이 가능하다.
Plane-level parallelism. 각 칩은 2개 이상의 플레인을 가지는데, 동일 오퍼레이션(Read, Write, Erase)은 하나의 칩내의 여러 플레인에 대해서 동시 실행이 될 수 있다. 플레인은 블록들을 가지며, 각 블록들은 다시 페이지들을 가진다. 또한 플레인은 플레인 단위의 오퍼레이션에 사용되는 레지스터를 가진다.

Interleaving

Interleaving 은 throughput을 늘리기 위한 기법 중 하나이다. Flash memory 의 경우 자체적으로 I/O Bus의 대역폭 제한이 있는데, 이를 극복하기 위해서 Multi channel 을 병렬적으로 활용하는 것이다

SSD 에서는 성능 향상을 위해 호스트로 받은 요청들을 여러 chip 으로 나누어서 동시에 처리할 수 있다. 한 페이지 이상의 요청에 대해서 여러 채널 으로 분산 저장하며 동시에 작업을 수행할 수 있어 throughput 을 증가시킬 수 있다.

Clustered block

여러 칩에 걸쳐서 한번에 접근할 수 있는 여러개의 블록을 "Clustered block" 이라고 한다. (RAID 시스템의 stripping 과 비슷함)

한번에 접근 가능한 논리 블록 주소들은 개별 플래시 패키지에서 서로 다른 SSD Chip에 걸쳐서 스트라이핑된다. 이는 FTL 의 매핑 알고리즘에 의해서 가능하다. 그 결과 스트라이핑 블록들은 여러 채널을 동시에 사용할 수 있으며 그 채널들의 대역폭을 묶어서 생각할 수 있으며 R/P/E 동작을 병렬로 수행할 수 있다. 이는 Clustered block 의 배수 사이즈의 operation 에 대해서 내부 병렬 능력 처리를 최대화할 수 있다.

Access

Sequential & Random I/O

"Sequential" 이라는 기준은 LBA 를 기준으로 하며, 연속된 LBA (이전 요청의 LBA 가 다음 LBA의 시작)인 경우이며, "Random" 의 기준은 "Sequential"이 아닌 모든 경우를 일컫는다.
- host 에서 시퀀셜하게 읽기 / 쓰기 요청을 하더라도 물리적으로는 연속된 위치에 있지 않을 가능성이 높다.
Sequential / Random 요청에 따라서 성능이 다르다. 일반적으로 순차적인 데이터 접근의 경우가 더 빠르다.

why? (해당 부분은 의문이 있어서 찾아본 바를 적어보겠다.)

Host 에서 순차적으로 바라보더라도, SSD 내에서 저장 될 때는 실제로 연속적인 것은 전혀 보장되지 않는다. 오히려 연속되지 않은 페이지를 사용할 가능성이 더 크다. 그렇다면 Random read 여도 사실 물리적으로는 크게 차이없는 것이 아닐까? 하는 의문이 들었다.
Sequential / Random 에 대한 use case 를 잘 생각해봐야한다. file 에 대한 I/O 로 생각을 해보면 Sequential / Random 은 다음과 같은 경우로 대입해볼 수 있다.
- Sequential -> 한 파일에 연속적인 I/O
- Random -> 여러 파일에 대해 I/O
실제 요청으로 바라보자면, Sequential 의 경우 "단일 요청" 이며 Random 의 경우 "다중 요청"으로 바라봐야한다. SSD Controller 입장에서는 한 요청을 수행하기 위해서 단순히 데이터를 읽고 쓰는 것 이외에도 메타데이터 탐색 / 저장과 같은 여러 과정이 포함되어야하는데, Random 의 경우는 Sequential 의 경우보다 해당 과정을 더 많이 수행해야만한다. 이러한 이유로 인해 Random Access 는 Sequential Access 에 비해서 더 느린 속도를 가지게 되는 것이다
후술하겠지만, Random / Sequential Read 모두 실제로 address 가 sequential 한지 아닌지에 대해서는 확실하지 않다. 하나의 채널에 연결된 블록에 접근할 수도, 아닐 수도 있다.

`Sequential Read/Write: data transfer rate while reading or writing data on a single file
* Respectively, random read/write indicates data transfer rate while reading or writing data on multiple files (ex. running a program). `

https://news.skhynix.com/sk-hynix-launches-2tb-gold-p31-ultra-low-power-solid-state-drive/

Random write 의 경우에서는 요청 사이즈에 따라 그 패턴이 다르다. Clustered block 의 사이즈보다 작은 경우에는 Sequential write 에 비해서 그 속도가 느리다. 그러나, Clustered block 의 사이즈보다 큰 경우, 동일하게 병렬처리 능력을 활용하여 비슷한 throughput을 가질 수 있다.
- 요청 사이즈가 작은 경우 metadata 관리가 더 빈번하게 일어나는 것이 주요 원인이다. 컨트롤러는 블록 매핑을 위한 metadata 관리를 해야하는데, Random write 의 경우 이 작업을 더 많이 수행해야한다.
Random read 의 경우에는 Write pattern 과 Read pattern 의 영향을 받는다. SSD 의 경우 FTL 에서 논리적 주소와 물리적 주소의 변환이 일어나며, 저장 시에 stripping 되어 저장된다. 따라서 Read를 할 때 실제 location 이 서로 같은 채널에 존재하는지 아닌지는 확신할 수 없다. 만약 read pattern 이 write pattern 이 유사하다면, 서로 다른 채널로 분산된 형태로 저장이 되어있어 보다 효과적일 것이다.
- Application program level 에서는 이를 최적화하기 위해 연관된 데이터를 같이 쓰는 것이 유리하며, 분할로 100MB 를 조회하는 것보다는 한번에 100MB를 조회하는 것이 내부적 병렬처리에서 유리하다.

NOTE

대부분의 문서가 2015년 이전의 문서로 현재 상황과는 다소 다를 수 있을것으로 짐작한다. 그러나, 전반적인 구조는 이전과 크게 다르지 않은 것으로 보인다.
참고한 많은 문서에서의 내용을 많이 요약하였다. 때문에 Reference 에 있는 문서들을 보는 것을 추천한다.

References

개발자를 위한 SSD(Coding for SSD)
- 상당히 잘 정리된 글, SSD 구조에 대해서 모르는 상태에서 접근하기 좋다.
- https://tech.kakao.com/posts/326
위 문서 관련 정리 글
- 빠르게 살펴보기 & 이해 안되는 부분 다르게 바라보기...
- Coding for SSD 만 정리한 게시물

Coding for SSD + 타 문서 함께 정리

SNU Advanced Operating System - Flash Memory
- 서울대학교 Advanced Operating System 강의에서 Flash Memory 부분 PPT
- http://csl.snu.ac.kr/courses/4190.568/2019-1/6-flash.pdf
A Reconfigurable FTL (Flash Translation Layer) Architecture for NAND Flash-Based Applications
- 현재 FTL 구조에 대해서 가볍게 설명하고 있으며, Reconfiguragble 한 FTL 을 만들기 위한 접근 방법에 대한 논문. FTL 에서 Address Mapping 관련하여 접근 방식에 대해서 살펴보기에 좋음
- http://csl.skku.edu/papers/tecs08.pdf
Parameter-Aware I/O Management For Solid State Disks (SSDs)
- http://csl.skku.edu/papers/CS-TR-2010-329.pdf
OSTEP - LFS
- FTL 의 경우 LFS의 방식을 차용하는데, OSTEP 의 LFS 파트. Log-structure 관련하여 기본 이론 지식을 습득하는데 도움됨.
- https://pages.cs.wisc.edu/~remzi/OSTEP/file-lfs.pdf
OSTEP - Locality and The Fast File System
- LFS 접근하면서 기존 Unix FS 에 대해서 살펴볼 때 살펴봄.
- https://pages.cs.wisc.edu/~remzi/OSTEP/file-ffs.pdf
Capple blog - SSD 이해
- SSD 의 물리적 구조를 이해하기 쉽게 그림으로 잘 설명해두었음.