Linux 파일 시스템 및 Persitent Memory 소개
참고: CSDN
Linux 파일 시스템 및 Persitent Memory 소개
1. 리눅스 가상 파일 시스템 소개
Linux 시스템에서는 모든 것이 파일이며, 일반적인 좁은 의미의 파일 외에도 디렉터리, 장치, 소켓, 파이프 등이 모두 파일입니다.
파일 시스템은 상황에 따라 다른 의미를 갖습니다.
데이터 구조 및 저장 장치에 대한 액세스 방법을 포함하여 저장 장치의 파일을 구성하는 방법입니다.
특정 파일 시스템 유형에 따라 포맷된 저장 매체입니다. 우리는 종종 특정 디렉터리에 파일 시스템을 마운트하거나 마운트 해제하는 것에 대해 이야기합니다. 이것이 여기서 파일 시스템이 의미하는 바입니다.
파일 관리 및 저장을 담당하는 커널의 모듈은 파일 시스템 모듈입니다.
Linux 파일 시스템의 아키텍처는 아래 그림에 표시되어 있으며 사용자 공간, 커널 공간 및 하드웨어의 세 가지 수준으로 나뉩니다.
참고: 위 그림에서는 커널 파일 시스템의 “캐시”와 “버퍼”의 차이를 구분할 수 없는 경우가 많습니다. 결국 둘 다 “캐시 영역”으로 번역될 수 있지만 그림에서는 매우 명확합니다. 소위 “캐시”는 실제로 그림에서 “페이지 캐시”를 의미하는 것을 알 수 있습니다. 파일용입니다. “DAX”(직접 액세스 모드 장치)를 제외하고는 “캐시”를 사용하지 않습니다. 기타 플래시 메모리 클래스, 블록 장치 장치는 모두 “페이지 캐시”(캐시)를 사용하며 “버퍼”는 실제로 그림의 “블록 캐시”를 의미하며 블록 장치를 의미합니다.
1.1 하드웨어 수준
외부 저장 장치는 블록 장치, 플래시 메모리, NVDIMM 장치의 세 가지 범주로 나뉘며, 블록 장치에는 두 가지 주요 유형이 있습니다.
기계식 하드 드라이브: 기계식 하드 드라이브의 읽기 및 쓰기 단위는 섹터입니다. 기계식 하드 디스크에 접근할 때 먼저 헤드를 반경을 따라 움직여 트랙을 찾은 다음 디스크를 회전시켜 섹터를 찾아야 합니다.
플래시 메모리 블록 장치: 플래시 메모리를 저장 매체로 사용하고 내부 컨트롤러는 견고한 드라이버를 실행합니다. 드라이버의 기능 중 하나는 플래시 메모리를 블록 장치로 변환하여 다음과 같이 나타나는 FTL(Flash Translation Layer)입니다. 블록 장비. 일반적인 플래시 메모리 블록 장치로는 개인용 컴퓨터, 노트북 등에 사용되는 SSD(Solid State Drive)와 내장형 멀티미디어 메모리 카드(휴대폰, 태블릿에 사용되는 내장형 멀티미디어 카드(eMMc) 및 범용 플래시 메모리)가 있다. 범용 플래시 스토리지, UFS). 기계식 하드 드라이브에 비해 플래시 메모리 블록 장치의 장점은 기계적 작동이 없기 때문에 빠른 액세스 속도, 높은 진동 저항 및 쉬운 휴대성입니다.
플래시 메모리의 주요 기능은 다음과 같습니다.
플래시 메모리에 데이터를 쓰면 한 비트만 1에서 0으로 바뀔 수 있고 0에서 1로 변경할 수 없기 때문에 데이터를 쓰기 전에 지우기 블록을 지워야 합니다. 지우기의 목적은 지우기 블록의 모든 비트를 1로 설정하는 것입니다. 1
삭제 블록의 최대 삭제 횟수는 제한되어 있습니다. NOR 플래시 메모리의 최대 삭제 블록 수는 10^4~10^3입니다. NAND 플래시 메모리의 최대 삭제 블록 수는 10^3~10^6입니다. …
플래시 메모리는 저장 구조에 따라 NAND 플래시 메모리와 NOR 플래시 메모리로 구분되는데, 둘의 차이점은 다음과 같습니다.
NOR 플래시 메모리는 용량이 작은 반면, NAND 플래시 메모리는 용량이 큽니다.
NOR 플래시 메모리는 바이트 주소 지정 및 인칩 실행을 지원합니다(eXecute In Place, 삭제 블록은 여러 페이지로 나뉘며 일부 NAND 플래시 메모리는 페이지를 여러 하위 페이지로 나눕니다.
NOR 플래시 메모리는 NAND 플래시 메모리보다 블록을 더 빠르게 읽고, NAND 플래시 메모리보다 느리게 쓰고 지웁니다.
NOR 플래시 메모리에는 불량 블록이 없습니다. NAND 플래시 메모리에는 불량 블록이 있습니다. 주로 불량 블록을 제거하는 비용이 너무 높기 때문입니다. NOR 플래시 메모리는 프로그램 저장에 적합하며 일반적으로 uboot 프로그램과 같은 부팅 프로그램을 저장하는 데 사용됩니다. NAND 플래시 메모리는 데이터를 저장하는 데 적합합니다.
파일 시스템을 플래시 메모리용으로 특별히 설계해야 하는 이유는 무엇입니까? 주요 이유는 다음과 같습니다.
NAND 플래시 메모리에는 불량 블록이 있으며, 소프트웨어는 불량 블록을 식별하고 건너뛰어야 합니다.
웨어 레벨링(Wear leveling)을 구현해야 하는데, 웨어 레벨링은 일부 삭제 블록이 먼저 손상되는 것을 방지하기 위해 모든 삭제 블록의 삭제 시간을 균등화하는 것입니다.
기계식 하드 드라이브와 NAND 플래시 메모리의 주요 차이점은 다음과 같습니다.
기계식 하드 디스크의 최소 읽기 및 쓰기 단위는 섹터이며 섹터의 크기는 일반적으로 512바이트입니다. NAND 플래시 메모리의 최소 읽기 및 쓰기 단위는 페이지 또는 서브페이지입니다.
기계식 하드 드라이브는 데이터를 직접 쓸 수 있습니다. NAND 플래시는 데이터를 쓰기 전에 삭제 블록을 지워야 합니다.
기계식 하드 디스크의 서비스 수명은 NAND 플래시 메모리보다 길습니다. 기계식 하드 디스크의 한 섹터에 대한 쓰기 수에는 제한이 없습니다. NAND 플래시의 삭제 블록에는 삭제 블록 수가 제한되어 있습니다. 메모리.
기계식 하드 디스크는 불량 섹터를 숨기며 소프트웨어는 불량 섹터를 처리할 필요가 없습니다. NAND 플래시 메모리의 불량 블록은 소프트웨어에 표시되며 소프트웨어는 불량 블록을 처리해야 합니다.
NVDIMM(Nonn-Volatile DIMM, 비휘발성 메모리: DIMM은 Dual-Inline-Memory-Modules의 약자로, 메모리 규격인 듀얼 인라인 메모리 모듈을 뜻함) 낸드 플래시 메모리와 메모리, 메모리를 결합한 장치 슈퍼커패시터가 함께 통합되어 액세스 속도가 메모리만큼 빠르며 정전 후에도 데이터가 손실되지 않습니다. 정전 순간 슈퍼커패시터는 메모리에 저장된 데이터를 낸드플래시 메모리로 전달할 수 있는 전력을 공급한다.
1.2 커널 공간 수준
커널 디렉토리 fs에서 볼 수 있듯이 커널은 여러 파일 시스템 유형을 지원합니다. 사용자 프로그램에 대한 통합된 파일 작업 인터페이스를 제공하고 다양한 파일 시스템 구현이 공존할 수 있도록 하기 위해 커널은 가상 파일 시스템 전환(Virtual File System Switching)이라고도 알려진 가상 파일 시스템(VFS)이라는 추상화 계층을 구현합니다. .VFS(Filesystem Switch) 파일 시스템은 다음과 같은 유형으로 구분됩니다.
블록 장치 파일 시스템. 저장 장치는 기계식 하드 디스크 및 솔리드 스테이트 드라이브와 같은 블록 장치입니다. 일반적으로 사용되는 블록 장치 파일 시스템은 EXT 및 btrfs입니다. EXT 파일 시스템은 Linux의 원래 파일 시스템으로 현재 3개의 성공적인 버전이 있습니다: EXT[2-4].
플래시 파일 시스템, 저장 장치는 NAND 플래시 메모리와 NOR 플래시 메모리이며 일반적으로 사용되는 플래시 파일 시스템은 JFFS2(Journaling Flash File System 버전 2, Journalling Flash File System 버전 2) 및 UBIFS(Unsorted Block Image File System, Unsorted Block Image)입니다. 파일 시스템). 메모리 파일 시스템의 파일은 메모리에 저장되어 있으며 정전 시 손실됩니다.일반적으로 사용되는 메모리 파일 시스템은 임시 파일을 생성하는 데 사용되는 tmpfs입니다.
의사 파일 시스템은 가상 파일 시스템의 프로그래밍 인터페이스를 사용하기 위한 가짜 파일 시스템입니다. 일반적으로 사용되는 의사 파일 시스템은 다음과 같습니다.
sockfs의 경우, 이 파일 시스템을 사용하면 소켓이 파일 읽기를 위해 읽기 인터페이스를 사용하여 메시지를 수신하고, 파일 쓰기를 위해 쓰기 인터페이스를 사용하여 메시지를 보낼 수 있습니다.
proc 파일 시스템은 원래 커널의 프로세스 정보를 사용자 공간으로 내보내기 위해 개발되었지만 나중에 커널의 모든 정보를 사용자 공간으로 내보내기 위해 확장되었습니다. proc 파일 시스템은 일반적으로 “proc” 디렉토리에 마운트됩니다.
sysfs는 커널 장치 정보를 사용자 공간으로 내보내는 데 사용됩니다. sysfs 파일 시스템은 일반적으로 “/sys” 디렉터리에 마운트됩니다.
표준 huge 페이지를 구현하는 데 사용되는 hugetlbfs.
cgroup 파일 시스템, 제어 그룹 cgroup은 프로세스 그룹의 리소스를 제어하는 데 사용됩니다.cgroup 파일 시스템을 사용하면 관리자는 파일을 작성하여 cgroup을 구성할 수 있습니다.
cgroup2 파일 시스템인 cgroup2는 cgroup의 두 번째 버전이며, cgroup2 파일 시스템을 사용하면 관리자가 파일을 작성하여 cgroup2를 구성할 수 있습니다.
이러한 각 파일 시스템에는 다음과 같은 관련 특성이 있습니다.
페이지 캐시: 외부 저장 장치에 접근하는 속도가 매우 느립니다. 파일을 읽거나 쓸 때마다 외부 저장 장치에 접근하는 것을 방지하기 위해 파일 시스템 모듈은 각 파일마다 메모리에 캐시를 생성합니다. 캐시 단위가 페이지이기 때문에 페이지 캐시라고 합니다.
블록 장치 계층: 블록 장치의 액세스 단위는 블록이고, 블록 크기는 섹터 크기의 정수배입니다. 커널은 모든 블록 장치에 대해 통합된 블록 장치 계층을 구현합니다.
블록 캐시: 모든 읽기 및 쓰기에 대해 블록 장치에 액세스할 필요가 없도록 하기 위해 커널은 블록 캐시를 구현하여 각 블록 장치에 대해 메모리에 블록 캐시를 생성합니다. 캐시 단위는 블록이며, 블록 캐시는 페이지 캐시를 기반으로 구현됩니다.
IO 스케줄러: 기계식 하드디스크에 접근할 때 트랙과 섹터를 찾기 위해 자기헤드를 움직여야 하는 시간이 많이 소요되는데, 읽기와 쓰기 요청을 섹터 번호에 따라 정렬하면 자기헤드의 이동을 줄이고 처리량이 향상될 수 있습니다. IO 스케줄러는 읽기 및 쓰기 요청의 제출 순서를 결정하는 데 사용되며 NOOP(No Operation), CFQ(Complete Fair Queuing) 및 최종 기한(deadline)과 같은 다양한 사용 시나리오에 대한 여러 예약 알고리즘을 제공합니다. NOOP 스케줄링 알고리즘은 플래시 메모리 블록 장치에 적합하고 CFQ 및 데드라인 스케줄링 알고리즘은 기계식 하드 디스크에 적합합니다.
블록 장치 드라이버: 각 블록 장치에는 자체 드라이버 구현이 필요합니다.
커널은 플래시 메모리를 MTD(Memory Technology Device)라고 부르며 모든 플래시 메모리에 대해 통합된 MTD 계층을 구현합니다. 각 플래시 메모리는 자체 드라이버를 구현해야 합니다. NVDIMM 장치의 경우 파일 시스템은 DAX(직접 액세스: 또는 커널의 가상 주소 공간)를 구현해야 합니다.
libnvdimm 하위 시스템은 세 가지 유형의 NVDIMM 장치, 즉 PMEM(영구 메모리) 모드의 NVDIMM 장치, BLK(블록 장치) 모드의 NVDIMM 장치, PMEM 및 BLK 액세스 모드를 모두 지원하는 NVDIMM 장치에 대한 지원을 제공합니다. PMEM 액세스 모드는 NVDIMM 장치를 메모리로 처리하고 BLK 액세스 모드는 NVDIMM 장치를 블록 장치로 처리합니다. 각 NVDIMM 장치에는 자체 드라이버 구현이 필요합니다.
2. 차세대 스토리지 기술 NVIDMM
NVDIMM(Non-Volatile Dual In-line Memory Module)은 무작위로 접근할 수 있는 비휘발성 메모리입니다. 비휘발성 메모리는 전원이 꺼져도 데이터가 사라지지 않는다는 뜻이다. 따라서 예상치 못한 정전, 시스템 충돌 및 컴퓨터의 정상적인 종료가 발생하는 경우에도 데이터는 계속 유지될 수 있습니다. NVDIMM은 또한 DIMM 패키지를 사용하고 표준 DIMM 슬롯과 호환되며 표준 DDR 버스를 통해 통신함을 나타냅니다. 비휘발성 특성과 기존 DRAM 인터페이스와의 호환성을 고려하여 영구 메모리라고도 합니다.
2.1 유형
현재 JEDEC 표준화 조직에서 정의한 대로 NVDIMM 구현에는 세 가지가 있습니다. 그들은:
NVDIMM-N
기존 DRAM과 플래시 메모리를 하나의 모듈에 동시에 탑재하는 것을 의미하며, 컴퓨터가 기존 DRAM에 직접 액세스할 수 있습니다. 바이트 주소 지정 및 블록 주소 지정을 지원합니다. 소형 백업 전원 공급 장치를 사용하면 정전 시 DRAM에서 플래시 메모리로 데이터를 복사한 다음 전원이 복구되면 DRAM에 다시 로드할 수 있는 충분한 전력이 제공됩니다.
NVDIMM-N 회로도
NVDIMM-N의 기본 작동 모드는 실제로 기존 DRAM과 동일합니다. 따라서 지연 시간도 10의 1나노초 제곱 정도입니다. 게다가 크기에 따라 용량이 제한되어 있어 기존 DRAM에 비해 개선된 부분이 없습니다.
동시에 작동 방식에 따라 플래시 부분을 주소 지정할 수 없으며 두 개의 미디어를 동시에 사용하면 비용이 크게 증가하지만 NVDIMM-N은 업계에 영구 메모리라는 새로운 개념을 제공합니다. 이미 시장에는 NVIMM-N 기반 제품이 많이 나와 있습니다.
NVDIMM-F
DRAM의 DDR3 또는 DDR4 버스를 사용하는 플래시 메모리를 말합니다. NAND 플래시를 매체로 사용하는 SSD는 일반적으로 SATA, SAS 또는 PCIe 버스를 사용하는 것으로 알려져 있습니다. DDR 버스를 사용하면 최대 대역폭을 늘리고 프로토콜로 인한 지연과 오버헤드를 어느 정도 줄일 수 있지만 블록 주소 지정만 지원합니다.
NVDIMM-F의 기본 작동 모드는 기본적으로 SSD의 작동 모드와 동일하므로 대기 시간은 10의 마이크로초 정도입니다. 용량도 TB를 쉽게 넘을 수 있습니다.
NVDIMM-P
아직 공개되지 않은 표준(개발 중)으로, DDR5 표준과 함께 출시될 것으로 예상됩니다. 계획에 따르면 DDR5는 DDR4보다 두 배의 대역폭을 제공하고 채널 효율성을 향상시킵니다. 서버 및 클라이언트 플랫폼을 위한 사용자 친화적인 인터페이스와 함께 이러한 개선 사항은 다양한 애플리케이션에서 고성능 및 향상된 전원 관리를 지원합니다.
NVDIMM-P는 실제로 실제 DRAM과 플래시의 하이브리드입니다. 이는 기존 DRAM과 유사한 블록 주소 지정과 바이트 주소 지정을 모두 지원합니다. NAND 플래시와 유사하게 TB 이상의 용량에 도달할 수 있을 뿐만 아니라 지연을 10^2 나노초로 유지할 수 있습니다.
데이터 매체를 메모리 버스에 직접 연결함으로써 CPU는 드라이버나 PCIe 오버헤드 없이 데이터에 직접 액세스할 수 있습니다. 그리고 메모리 액세스는 64바이트 캐시 라인을 통해 이루어지기 때문에 CPU는 일반 블록 장치처럼 매번 블록 단위로 액세스하는 것이 아니라 필요한 데이터에만 액세스하면 됩니다.
Intel Corporation은 2018년 5월에 3D XPoint™ 기술을 기반으로 한 Intel® Optane™ DC 영구 메모리를 출시했습니다. NVDIMM-P의 구현이라고 볼 수 있습니다.
인텔® Optane™ DC 영구 메모리
2.2 하드웨어 지원
애플리케이션은 기존 DRAM과 마찬가지로 NVDIMM-P에 직접 액세스할 수 있습니다. 또한 기존 블록 장치와 메모리 간의 페이지 교환이 필요하지 않습니다. 그러나 영구 메모리에 데이터를 쓰는 것은 일반 DRAM에 데이터를 쓰는 것과 컴퓨터 리소스를 공유합니다. 프로세서 버퍼, L1/L2 캐시 등 포함
데이터의 내구성을 유지하려면 데이터가 영구 메모리 장치 또는 전원 차단 보호 기능이 있는 버퍼에 기록되도록 해야 합니다. 소프트웨어가 영구 메모리의 기능을 최대한 활용하려면 명령어 세트 아키텍처에 최소한 다음 지원이 필요합니다.
글쓰기의 원자성
시스템 충돌이나 갑작스러운 정전을 방지하려면 영구 메모리에 있는 모든 크기의 쓰기가 원자성으로 보장되어야 함을 나타냅니다. IA-32 및 IA-64 프로세서는 최대 64비트의 캐시된 데이터 액세스(정렬 또는 비정렬)에 대한 쓰기 원자성을 보장합니다. 따라서 소프트웨어는 영구 메모리의 데이터를 안전하게 업데이트할 수 있습니다. 또한 쓰기 원자성을 보장하기 위해 쓰기 시 복사 또는 미리 쓰기 로깅의 오버헤드를 제거하므로 성능이 향상됩니다.
효율적인 캐시 플러시
성능상의 이유로 영구 메모리 데이터는 액세스하기 전에 먼저 프로세서의 캐시에 배치되어야 합니다. 최적화된 캐시 플러시 명령은 플러시(CLFLUSH)로 인한 성능 영향을 줄입니다.
a. CLFLUSHOPT는 보다 효율적인 캐시 새로 고침 명령을 제공합니다.
b. CLWB(Cache Line Write Back) 명령은 캐시 라인의 변경된 데이터를 메모리에 다시 쓰지만(CLFLUSHOPT와 유사) 이 캐시 라인을 잘못된 상태(잘못된 MESI 프로토콜)로 변환할 필요는 없습니다. 그러나 변하지 않은 상태로, Exclusive 상태(Exclusive)입니다. CLWB 명령어는 실제로 특정 캐시 라인 새로 고침으로 인해 다음 액세스 시 불가피한 캐시 누락을 줄이려고 노력하고 있습니다.
지속성에 대한 헌신
최신 컴퓨터 아키텍처에서 캐시 플러시가 완료되면 수정된 데이터가 메모리 하위 시스템의 쓰기 버퍼에 다시 기록되었음을 나타냅니다. 그러나 현재로서는 데이터가 지속되지 않습니다. 데이터가 영구 메모리에 기록되도록 하려면 소프트웨어는 메모리 하위 시스템의 휘발성 쓰기 버퍼 또는 기타 캐시를 플러시해야 합니다. 영구 쓰기를 위한 새로운 커밋 명령 PCOMMIT는 메모리 하위 시스템 쓰기 대기열의 데이터를 영구 메모리에 커밋할 수 있습니다.
비임시적 매장 최적화
소프트웨어가 일반 메모리에서 영구 메모리로 대량의 데이터를 복사해야 하는 경우(또는 영구 메모리 간 복사) 약한 순차, 비일시적 저장 작업(예: MOVNTI 명령어 사용)을 사용할 수 있습니다. 비임시 저장 지시어는 다시 쓰여지는 캐시 라인을 암시적으로 무효화하기 때문에 소프트웨어는 캐시 라인을 명시적으로 플러시할 필요가 없습니다(Intel® 64 및 IA-32 아키텍처 소프트웨어 개발자 매뉴얼, 볼륨 1의 섹션 10.4.6.2 참조).
요약
위에서는 NVDIMM의 여러 구현 방법과 NVDIMM-P의 성능을 극대화하기 위한 하드웨어 최적화 및 지원을 소개합니다. 다음에는 프로그래밍 모델, 프로그래밍 라이브러리, SPDK 지원 등을 포함한 소프트웨어 지원이 계속해서 소개됩니다.
NVDIMM에 대한 이전 소개에서는 NVDIMM의 여러 하드웨어 구현과 성능을 지원하고 최적화하기 위한 하드웨어 변경 사항에 대해 설명했습니다. 다음으로 NVDIMM의 성능을 최대한 활용하기 위해 어떤 소프트웨어 지원이 제공되는지 살펴보겠습니다. 어떤 사람들은 질문을 할 수도 있습니다. 왜 사용하기가 그렇게 번거롭습니까? 영구 메모리이기 때문에 컴퓨터를 종료하고 켜는 데 충분하지 않습니까? 사실, 현재 이 아이디어는 현실이 되지 않을 것입니다. 캐시와 같이 휘발성인 DRAM 외에 레지스터도 휘발성이기 때문입니다. 단순히 메모리를 지속적으로 만드는 것만으로는 이 목표를 달성할 수 없습니다. 또 다른 문제는 메모리 누수입니다. 메모리 누수가 발생하면 다시 시작하세요. 지속적인 메모리 누수라면 어떻게 되나요? 이것은 또한 매우 어려운 질문입니다. Pmem은 어떤 측면에서는 메모리와 유사하고 어떤 측면에서는 스토리지와 유사합니다. 그러나 우리는 일반적으로 Pmem을 메모리나 스토리지의 대체물로 생각하지 않습니다. 사실상 메모리와 스토리지 사이의 엄청난 격차를 메워주는 보완책이라고 볼 수 있다.
공식 계정 탑 아키텍트 백엔드에 “Neat Architecture”라고 답하시면 깜짝 선물을 받으실 수 있습니다.
SPDK는 17.10부터 Pmem에 대한 지원을 도입하기 시작했습니다. Pmem은 SPDK의 bdev 계층에서 블록 장치로 노출되며 빠른 장치 인터페이스를 사용하여 상위 계층과 통신합니다. 아래 그림과 같이.
그림에서 libpmemblk가 블록 작업을 바이트 작업으로 변환하는 것을 볼 수 있습니다. 어떻게 이루어 집니까? libpmemblk와 그 뒤에 있는 PMDK를 소개하기 전에 기본 사항을 이해해 보겠습니다.
mmap 및 DAX
먼저 전통적인 I/O 방식, 즉 캐시된 I/O(Buffered I/O)를 살펴보자.대부분의 운영체제의 기본 IO 동작 방식은 캐시된 IO이다. 이 메커니즘은 IO 데이터가 운영 체제의 페이지 캐시에 캐시되도록 합니다. 즉, 데이터가 먼저 운영 체제의 커널 공간 버퍼에 복사된 다음 커널 공간의 버퍼에서 복사됩니다. 지정된 사용자 주소 공간으로. .
Linux에서는 위 그림과 같이 읽기/쓰기 시스템 호출을 통해 파일에 액세스하는 이러한 방식이 달성됩니다. 다음으로 메모리 매핑된 IO mmap()을 비교해 보겠습니다.
다음으로 메모리 매핑된 IO mmap()을 비교해 보겠습니다.
mmap을 통해 해당 파일에 대한 포인터를 얻은 후 값을 할당하거나 연산 메모리와 마찬가지로 memcpy/strcpy를 수행하는 것을 로드/스토어 작업이라고 합니다.(일반적으로 이 작업을 다운로드하려면 msync 및 fsync가 필요합니다.)
mmap은 파일과 사용자 공간 간의 매핑 관계를 설정하므로 파일을 사용자 공간에 직접 복사하여 데이터 복사본을 하나 줄이는 것으로 간주할 수 있습니다. 하지만 mmap은 여전히 페이지 캐시에 의존해야 합니다.
mmap에 대해 이야기한 후, DAX란 무엇입니까? DAX는 Direct Access를 의미하며, 이 기능은 mmap을 기반으로 합니다. DAX의 차이점은 페이지 캐시가 전혀 필요하지 않고 스토리지 장치에 직접 액세스한다는 점이므로 NVDIMM용으로 탄생했습니다. mmap에 대한 애플리케이션의 파일 작업은 NVDIMM에 직접 동기화됩니다. DAX는 현재 Windows의 XFS, EXT4 및 NTFS에서 지원됩니다. 이 모드를 사용하려면 애플리케이션이나 파일 시스템을 수정해야 합니다.
2.3 NVM 프로그래밍 모델
NVM 프로그래밍 모델은 대략 세 가지 사용 방법을 정의합니다.
2.3.1 맨 왼쪽의 관리는 주로 드라이버에서 제공하는 API를 통해 용량 정보 보기, 상태, 펌웨어 버전, 펌웨어 업그레이드, 모드 구성 등 NVDIMM을 관리합니다.
2.3.2 중간에는 NVDIMM 드라이버를 지원하는 파일 시스템과 커널을 사용하여 빠른 저장 장치로 사용되며, 응용프로그램은 별도의 수정이 필요 없으며 표준 파일 인터페이스를 통해 NVDIMM에 접근한다.
2.3.3 세 번째 유형은 파일 시스템의 DAX 기능을 기반으로 하며 로드/저장 작업을 통해 페이지 캐시, 동기 디스크 배치, 시스템 호출 및 중단이 필요하지 않습니다. 이는 NVDIMM의 성능 이점을 완전히 활용할 수 있는 NVM 프로그래밍 모델의 핵심이기도 합니다. 단점은 응용 프로그램을 변경해야 할 수도 있다는 것입니다.
PMDK
libpmemblk는 pmem에 있는 동일한 크기의 블록 배열을 구현합니다. 갑작스러운 정전, 프로그램 충돌 등에도 불구하고 그 안에 있는 각 블록은 여전히 원자 트랜잭션을 유지합니다. libpmemblk는 특히 플러시 지원을 위해 PMDK에서 제공되는 하위 수준 라이브러리인 libpmem 라이브러리를 기반으로 합니다. pmem의 모든 저장 작업을 추적하고 데이터가 영구 데이터로 디스크에 기록되는지 확인할 수 있습니다.
또한 PMDK는 libpmemobj, libpmemlog, libvmmalloc 등과 같은 다른 프로그래밍 라이브러리도 제공합니다. 관심이 있으시면 홈페이지를 방문하시면 더 많은 정보를 보실 수 있습니다.
결론
이제 모든 사람은 NVDIMM 하드웨어와 소프트웨어의 차이점을 전반적으로 이해하게 되었습니다. Intel은 2018년 5월 3D XPoint™ 기술 기반 Intel® Optane™ DC 영구 메모리를 출시하여 NVDIMM 폭발을 촉발했습니다.
2.4 위의 내용은 다음과 같이 요약할 수 있다.
NVIDMM 분류
NVIDMM-N: 메모리 매핑 DRAM, 문자 액세스 인터페이스 제공, 세 제품 중 성능은 가장 좋고 용량은 가장 작습니다.
NVDIMM-F: 메모리 매핑된 플러시, 블록 장치 인터페이스만 제공합니다. Nand Flush는 메모리 컨트롤러 채널에 직접 연결됩니다.
NVIDMM-P: 개발 중이며 블록 장치 및 문자 장치 액세스 인터페이스를 제공합니다.
특성
NVDIMM-N: NVDIMM-N은 캐시와 블록 스토리지 장치로 모두 사용될 수 있습니다. 대표적인 것이 인텔과 같은 AEP이다.
NVIDMM-F: 주로 캐시에 사용되는 NVIDMM-N과 달리 NVIDMM-F는 주로 저장에 사용됩니다. 고밀도 메모리 풀 스토리지 풀을 신속하게 구축하는 데 사용할 수 있습니다.
2.4.1 NVDMM 기반 파일 시스템 구축
PMEM을 위해 설계된 파일 시스템은 NOVA Filesystem이며 관심 있는 독자는 NOVA의 github을 참조할 수 있습니다.
ZUFS는 NetApp의 프로젝트로, ZUFS의 전체 이름은 Zero-copy User Filesystem입니다. 완전한 제로 카피를 달성했다고 주장하며, 파일 시스템의 메타데이터도 제로 카피입니다. ZUFS는 주로 PMEM용으로 설계되었지만 기존 디스크 장치도 지원할 수 있으며 FUSE의 제로 복사 버전과 동일하며 FUSE의 성능을 향상시킵니다.
DRAM으로 사용되는 모드:
2.4.2.1 시스템 전반에 걸친 정전 보호 지원 많은 시나리오에서 비정상적인 정전 및 데이터 손실을 방지하기 위해 커밋 및 플러시의 2단계 커밋 및 플러시 방법을 쓰기 시 1단계 커밋 방식으로 생략할 수 있습니다.
2.4.2.2 DRAM과 SSD 물리학 사이에 새로운 스토리지 레이어 제공
2.4.2.3 DRAM으로 사용하는 경우 액세스 속도는 SSD보다 1~3배 더 높을 수 있습니다. 일부 파일 시스템에서는 페이지 캐시에 대한 의존성을 제거할 수 있어 상위 메모리의 평균 지연 및 대기 시간을 더 잘 제어할 수 있습니다. -계층 서비스 서비스 안정성.
DAX: 이름에서 알 수 있듯이 DAX는 페이지 캐시를 우회하는 직접 액세스입니다. PMEM에서 직접 데이터를 읽고 쓰려면 파일 시스템을 마운트할 때 “-o dax” 매개변수를 추가해야 합니다. DAX는 PMEM 장치의 파일 시스템 성능을 크게 향상시켰지만 다음과 같이 아직 해결되지 않은 몇 가지 문제가 있습니다.
파일 시스템의 메타데이터는 여전히 페이지 캐시나 버퍼 캐시를 사용해야 합니다.
“-o dax” 마운트 옵션은 전체 파일 시스템에 적용되며 더 세부적인 제어를 제공할 수 없습니다.
2.4.3 DAX에서 액세스할 수 있는 파일에 액세스할 수 있는지 여부를 애플리케이션에 알려주는 API가 없습니다.
3. Linux에서 NVDIMM 구현
영구 메모리는 동적 RAM(DRAM)만큼 빠르지만 RAM의 바이트 주소 지정 기능과 솔리드 스테이트 드라이브(SSD)의 성능을 갖춘 새로운 유형의 컴퓨터 스토리지입니다. 마더보드의 메모리 슬롯에 있습니다. 따라서 DIMM 형태로 사용 가능한 RAM과 동일한 물리적 폼 팩터를 갖습니다. 이러한 메모리를 NVDIMM(비휘발성 듀얼 인라인 메모리 모듈)이라고 합니다.
그러나 RAM과 달리 영구 메모리는 여러 면에서 플래시 기반 SSD와 유사합니다. 후자의 두 개는 솔리드 스테이트 메모리 회로의 형태를 취하지만 둘 다 비휘발성 저장소를 제공합니다. 즉, 시스템 전원을 끄거나 다시 시작한 후에도 메모리 내용이 유지됩니다. 두 미디어 모두 데이터 쓰기가 데이터 읽기보다 느리며 둘 다 제한된 수의 다시 쓰기 주기를 지원합니다. 마지막으로 SSD와 마찬가지로 특정 애플리케이션에 더 적합한 경우 영구 메모리에 대한 섹터 수준 액세스를 사용할 수 있습니다.
모델마다 Intel 3D XPoint 또는 NAND 플래시 메모리와 DRAM의 조합과 같은 다양한 형태의 전자 저장 매체를 사용합니다. 또한 업계에서는 새로운 형태의 비휘발성 RAM을 개발하고 있습니다. 이는 다양한 공급업체와 NVDIMM 모델이 서로 다른 성능과 내구성 특성을 제공한다는 것을 의미합니다.
관련된 스토리지 기술은 개발 초기 단계에 있으므로 공급업체의 하드웨어마다 제한 사항이 다를 수 있습니다. 따라서 다음 설명은 일반적인 상황에 적용됩니다.
영구 메모리는 DRAM보다 최대 10배 느리지만 플래시 메모리보다 약 1,000배 빠릅니다. 전체 섹터를 지운 다음 다시 써야 하는 플래시 메모리와 달리 데이터는 바이트 단위로 다시 쓸 수 있습니다. 다시 쓰기 주기 수는 제한되어 있지만 대부분의 영구 메모리 형태는 수천 주기만 처리할 수 있는 플래시 메모리에 비해 수백만 번의 다시 쓰기를 처리할 수 있습니다.
이는 두 가지 중요한 결과를 가져옵니다. 최신 기술을 사용하여 영구 메모리만으로 시스템을 실행하는 것은 불가능하므로 완전한 비휘발성 메인 메모리를 달성할 수 없으며 기존 RAM과 NVDIMM을 혼합하여 사용해야 합니다. 운영 체제와 애플리케이션은 기존 RAM에서 실행되는 반면 NVDIMM은 매우 빠른 보완 스토리지를 제공합니다.
영구 메모리의 성능 특성은 공급업체마다 다르기 때문에 프로그래머는 NVDIMM 수와 적합한 메모리 슬롯을 포함하여 특정 서버의 NVDIMM 하드웨어 사양을 고려해야 할 수 있습니다. 분명히 이는 하이퍼바이저 사용, 서로 다른 호스트 간의 소프트웨어 마이그레이션 등에 영향을 미칠 것입니다.
이 새로운 저장소 하위 시스템은 ACPI 표준 버전 6에 정의되어 있습니다. 그러나 libnvdimm은 사전 표준 NVDIMM을 지원하며 이러한 메모리를 동일한 방식으로 사용할 수 있습니다.
3.1 영구 메모리(PMEM)
RAM과 마찬가지로 PMEM 스토리지는 바이트 수준 액세스를 제공합니다. PMEM을 사용하는 경우 단일 네임스페이스에는 인터리브된 여러 NVDIMM이 포함될 수 있으므로 NVDIMM이 단일 장치로 작동할 수 있습니다. PMEM 네임스페이스를 구성하는 방법에는 두 가지가 있습니다.
DAX와 함께 PMEM 사용
PMEM 네임스페이스가 DAX(직접 액세스)용으로 구성된 경우 메모리 액세스는 커널의 페이지 캐시를 우회하고 미디어로 직접 이동합니다. 소프트웨어는 이 네임스페이스의 각 바이트를 개별적으로 직접 읽거나 쓸 수 있습니다.
BTT와 함께 PMEM 사용
RAM과 같은 바이트 주소 지정 가능 모드가 아닌 기존 디스크 드라이브와 같은 BTT 모드에서 실행되는 PMEM 네임스페이스에 대한 섹터별 액세스를 구성합니다. 변환 테이블 메커니즘은 액세스 활동을 섹터 크기 단위로 일괄 처리합니다.
BTT의 장점은 스토리지 하위 시스템이 각 섹터가 기본 미디어에 완전히 기록되도록 보장하고 어떤 이유로 쓰기 작업이 실패하면 작업이 등록 취소된다는 것입니다. 따라서 특정 섹터에서는 부분 쓰기를 수행할 수 없습니다. 또한 BTT 네임스페이스에 대한 액세스는 커널에 의해 캐시됩니다. 단점은 BTT 네임스페이스가 DAX를 지원하지 않는다는 것입니다.
3.2 영구 메모리 관리 도구
영구 메모리를 관리하려면 ndctl 패키지를 설치해야 합니다. 이 패키지를 설치하면 NVDIMM 구성을 위한 사용자 공간 라이브러리 세트를 제공하는 libndctl 패키지도 설치됩니다. 이러한 도구는 libnvdimm 라이브러리를 통해 실행됩니다. 라이브러리는 세 가지 유형의 NVDIMM을 지원합니다.
PMEM
블랙
PMEM과 BLK를 동기화합니다.
ndctl 유틸리티는 다음 명령을 사용하여 액세스할 수 있는 일련의 유용한 매뉴얼 페이지를 제공합니다.
ndctl help subcommand
사용 가능한 하위 명령 목록을 보려면 다음을 사용하세요.
ndctl --list-cmds
사용 가능한 하위 명령은 다음과 같습니다.
- 버전: NVDIMM 지원 도구의 현재 버전을 표시합니다.
- 활성화-네임스페이스: 지정된 네임스페이스를 사용할 수 있도록 만듭니다.
- 비활성화 네임스페이스: 지정된 네임스페이스의 사용을 방지합니다.
- create-namespace: 지정된 저장 장치에서 새 네임스페이스를 생성합니다.
- destroy-namespace: 지정된 네임스페이스를 제거합니다.
- 활성화 지역: 지정된 지역을 사용할 수 있도록 만듭니다.
- 비활성화 지역: 지정된 지역의 사용을 방지합니다.
- zero-labels: 장치에서 메타데이터를 삭제합니다.
- read-labels: 지정된 장치에 대한 메타데이터를 검색합니다.
- 목록: 사용 가능한 장치를 표시합니다.
- help: 도구 사용에 대한 정보를 표시합니다.
3.3 영구 메모리 설정
3.3.1 사용 가능한 NVDIMM 스토리지 보기
ndctl list 명령을 사용하면 시스템에서 사용 가능한 모든 NVDIMM을 나열할 수 있습니다. 다음 예에서 시스템은 단일 3채널 인터리브 세트 내에 3개의 NVDIMM을 포함합니다.
ndctl list --dimms
[
{
"dev":"nmem2",
"id":"8089-00-0000-12325476"
},
{
"dev":"nmem1",
"id":"8089-00-0000-11325476"
},
{
"dev":"nmem0",
"id":"8089-00-0000-10325476"
}
]
다른 매개변수와 결합하면 ndctl list는 사용 가능한 영역을 나열할 수도 있습니다.
참고: 지역은 번호순으로 표시되지 않을 수 있습니다.
NVDIMM은 3개만 있지만 4개의 지역으로 나타납니다.
ndctl list --regions
[
{
"dev":"region1",
"size":68182605824,
"available_size":68182605824,
"type":"blk"
},
{
"dev":"region3",
"size":202937204736,
"available_size":202937204736,
"type":"pmem",
"iset_id":5903239628671731251
},
{
"dev":"region0",
"size":68182605824,
"available_size":68182605824,
"type":"blk"
},
{
"dev":"region2",
"size":68182605824,
"available_size":68182605824,
"type":"blk"
}
]
공간은 BLK 유형의 개별 64GB 영역 3개, 인터리브된 NVDIMM 3개의 모든 공간을 단일 볼륨으로 나타내는 PMEM 유형의 통합 189GB 영역 등 두 가지 형태로 표시됩니다.
available_size의 표시된 값은 표시된 size 값과 동일합니다. 이는 아직 공간이 할당되지 않았음을 의미합니다.
3.3.2 DAX와 함께 단일 PMEM 네임스페이스를 사용하도록 스토리지 구성
첫 번째 예에서는 DAX(Direct Access)를 사용하여 3개의 NVDIMM을 단일 PMEM 네임스페이스로 구성합니다. 첫 번째 단계는 새 네임스페이스를 만드는 것입니다.
ndctl create-namespace --type=pmem --mode=fsdax --map=memory
{
"dev":"namespace3.0",
"mode":"memory",
"size":199764213760,
"uuid":"dc8ebb84-c564-4248-9e8d-e18543c39b69",
"blockdev":"pmem3"
}
그러면 DAX 지원 블록 장치 /dev/pmem3이 생성됩니다. 장치 이름의 3은 상위 지역 번호(이 경우 지역 3)에서 상속됩니다.
–map=memory 옵션은 구조 페이지라는 내부 커널 데이터 구조를 할당하는 데 사용할 수 있도록 NVDIMM에서 PMEM 저장 공간의 일부를 설정합니다. 이를 통해 O_DIRECT I/O 및 RDMA와 같은 기능을 갖춘 새로운 PMEM 네임스페이스를 사용할 수 있습니다.
영구 메모리의 일부가 커널 데이터 구조용으로 예약되어 있으므로 최종 PMEM 네임스페이스 크기는 상위 PMEM 영역보다 작습니다.
다음으로 운영 체제에서 새 블록 장치를 사용할 수 있는지 확인합니다.
fdisk -l /dev/pmem3
Disk /dev/pmem3: 186 GiB, 199764213760 bytes, 390164480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
다른 드라이브와 마찬가지로 장치도 사용하기 전에 포맷해야 합니다. 이 예에서는 XFS를 사용하여 형식을 지정합니다.
mkfs.xfs /dev/pmem3
…
다음으로 새 드라이브를 디렉터리에 마운트할 수 있습니다.
mount -o dax /dev/pmem3 /mnt/pmem3
그런 다음 DAX 지원 디바이스를 얻었는지 확인할 수 있습니다.
mount | grep dax
/dev/pmem3 on /mnt/pmem3 type xfs (rw,relatime,attr2,dax,inode64,noquota)
결과적으로 우리는 XFS 파일 시스템으로 포맷되고 DAX를 갖춘 PMEM 네임스페이스를 갖게 되었습니다.
프로그래밍 테크놀로지 서클 공식 계정 백그라운드에서 “Java”라고 답하시면 깜짝 선물을 받으실 수 있습니다.
이 파일 시스템의 파일에 대한 mmap() 호출은 NVDIMM의 영구 메모리에 직접 매핑되는 가상 주소를 반환하고 페이지 캐시를 완전히 우회합니다. 이 파일 시스템의 파일에 대한 fsync 또는 msync 호출은 수정된 데이터가 NVDIMM에 완전히 기록되었는지 확인합니다. 이러한 호출은 mmap 매핑을 통해 사용자 공간에서 수정된 모든 페이지에 대해 연관된 프로세서 캐시 라인을 플러시합니다.
3.3.2.1 네임스페이스 제거
동일한 스토리지를 사용하여 다른 유형의 볼륨을 생성하기 전에 이 PMEM 볼륨을 마운트 해제한 다음 제거해야 합니다.
먼저 볼륨을 마운트 해제합니다.
umount /mnt/pmem3
그런 다음 네임스페이스를 비활성화합니다.
ndctl disable-namespace namespace3.0
disabled 1 namespace
그런 다음 볼륨을 삭제합니다.
ndctl destroy-namespace namespace3.0
destroyed 1 namespace
3.3.3 BTT를 사용하여 PMEM 네임스페이스 생성
다음 예에서는 BTT를 사용하여 PMEM 네임스페이스를 생성합니다.
ndctl create-namespace --type=pmem --mode=sector
{
"dev":"namespace3.0",
"mode":"sector",
"uuid":"51ab652d-7f20-44ea-b51d-5670454f8b9b",
"sector_size":4096,
"blockdev":"pmem3s"
}
다음으로 새 장치가 존재하는지 확인합니다.
fdisk -l /dev/pmem3s
Disk /dev/pmem3s: 188.8 GiB, 202738135040 bytes, 49496615 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
이전에 구성된 DAX 지원 PMEM 네임스페이스와 마찬가지로 이 BTT 지원 PMEM 네임스페이스도 NVDIMM에서 사용 가능한 모든 스토리지를 차지합니다.
참고: 장치 이름(/dev/pmem3s)의 후행 s는 섹터를 나타내며 BTT를 사용하도록 구성된 네임스페이스를 쉽게 식별하는 데 사용할 수 있습니다.
이전 예에서 설명한 대로 볼륨을 포맷하고 마운트할 수 있습니다.
여기에 표시된 PMEM 네임스페이스는 DAX를 사용할 수 없으며 BTT를 사용하여 섹터 쓰기 원자성을 제공합니다. PMEM 블록 드라이버를 통해 섹터 쓰기가 발생할 때마다 BTT는 새 데이터를 수신하기 위해 새 섹터를 할당합니다. 새 데이터가 완전히 기록되면 BTT는 내부 매핑 구조를 원자적으로 업데이트하여 새로 작성된 데이터를 애플리케이션에서 사용할 수 있도록 합니다. 프로세스 중 어느 시점에서든 정전이 발생하면 쓰기가 완전히 손실되며, 이 경우 애플리케이션은 변경되지 않은 이전 데이터에 액세스할 수 있습니다. 이는 “섹터 찢어짐”으로 알려진 현상을 방지합니다.
다른 표준 블록 장치와 마찬가지로 이 BTT 지원 PMEM 네임스페이스는 파일 시스템으로 포맷하고 해당 파일 시스템 내에서 사용할 수 있습니다. 이 네임스페이스는 DAX와 함께 사용할 수 없습니다. 그러나 이 블록 장치에 있는 파일의 mmap 매핑은 페이지 캐시를 사용합니다.
3.4 메모리(DRAM)를 사용하여 영구 메모리(영구 메모리) 시뮬레이션
3.4.1 라이트 버전: 일반 커널에서는 영구 메모리 시뮬레이션을 수행하는 데 두 단계만 필요합니다.
1) 그럽 구성:
vim /etc/default/grub
내부에 다음 문장을 추가합니다. 전자는 시뮬레이션할 크기이고, 후자는 메모리 내 시뮬레이션된 영구 메모리의 시작 위치입니다. 즉, 4G 메모리부터 시작하여 32G로 나누어 영구 메모리를 시뮬레이션하는 것입니다.
GRUB_CMDLINE_LINUX=”memmap=32G!4G”
2) 그럽 업데이트
update-grub && reboot
3.4.2 심층분석
현재 실제 영속성 메모리는 일반 사용자가 사용할 수 없으며, 실험 및 테스트 과정에서 영속성 메모리를 시뮬레이션하여 사용할 필요가 있을 수 있으며, 현재는 호스트에서 메모리 영역을 나누어 영속성 메모리를 시뮬레이션하기 위한 테스트를 진행하고 있습니다.
환경: Ubuntu 18.04, 8G 실행 메모리를 갖춘 일반 Dell 데스크탑 컴퓨터.
Linux 커널은 Linux 4.0부터 영구 메모리 장치 및 에뮬레이션을 지원해 왔지만 구성의 용이성을 위해 4.2보다 최신 커널을 사용하는 것이 좋습니다. 커널에서는 파일 시스템에 대한 DAX 확장을 사용하여 PMEM 지원 환경이 생성됩니다. 일부 배포판(예: Fedora 24 이상)에는 DAX/PMEM 지원이 내장되어 있습니다.
커널이 DAX 및 PMEM을 지원하는지 확인하려면 다음 명령을 사용할 수 있습니다.
# egrep '(DAX|PMEM)' /boot/config-`uname –r`
지원이 내장된 경우 다음과 유사한 내용이 출력됩니다.
CONFIG_X86_PMEM_LEGACY_DEVICE=y
CONFIG_X86_PMEM_LEGACY=y
CONFIG_BLK_DEV_RAM_DAX=y
CONFIG_BLK_DEV_PMEM=m
CONFIG_FS_DAX=y
CONFIG_FS_DAX_PMD=y
CONFIG_ARCH_HAS_PMEM_API=y
안타깝게도 Ubuntu 18.04에는 DAX/PMEM을 기본적으로 지원하지 않으므로 위 명령을 입력해도 출력이 없습니다. 다음으로 Ubuntu 18.04에서 영구 메모리를 시뮬레이션합니다. Ubuntu 18.04에서는 DAX 및 PMEM이 기본적으로 지원되지 않으므로 커널을 다시 컴파일하고 컴파일된 커널의 구성 옵션에 관련 설정을 추가해야 합니다.
여기에서 커널을 다시 컴파일하면 선택한 버전은 Linux-4.15입니다.
먼저 다음 명령을 입력하십시오.
make nconfig
PMEM 및 DAX를 구성하려면 다음 구성 인터페이스를 입력하십시오.
Device Drivers
NVDIMM Support
<M>PMEM;
<M>BLK;
<*>BTT
<*>NVDIMM DAX
PMEM 구성
먼저 장치 드라이버에 들어가서 장치 드라이버에서 NVDIMM 지원을 찾으세요. 메뉴 표시줄을 아래로 스크롤해야 합니다. 내부 내용은 우리가 보는 첫 페이지만이 아닙니다. NVDIMM 지원은 첫 페이지에 없습니다.
NVDIMM 지원으로 이동하여 내부의 모든 항목을 선택하세요.
<M>PMEM;
<M>BLK;
<*>BTT
<*>NVDIMM DAX
파일 시스템 DAX 구성
esc를 사용하여 make nconfig의 초기 페이지로 돌아갑니다.
File System
<*>Direct Access support
프로세서 기능 설정
esc를 사용하여 make nconfig의 초기 페이지로 돌아갑니다.
Processor type and features
<*>Support non-standard NVDIMMs and ADR protected memory
사실 Linux-4.15에서는 위의 모든 과정이 기본적으로 이루어졌는데, 즉 nconfig만 만들어주면 됩니다.
모든 구성이 완료되면 커널 컴파일 및 설치를 시작합니다.
# make -j9
# make modules_install install
그런 다음 새로 컴파일된 커널 Linux-4.15를 입력하세요.
e820 테이블을 인쇄하려면 다음 명령을 사용하십시오.
| dmesg | grep e820 |
다음 콘텐츠를 얻으세요:
[0.000000] e820: BIOS-provided physical RAM map:
[0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
[0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
...
위의 사용 가능 항목은 우리가 사용할 수 있는 것으로, 일부 영역을 영구 메모리로 나눌 수 있습니다. 다음을 선택하는 것이 좋습니다.
[0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000021f5fffff] usable
그 중 0x0000000100000000은 4G이므로 grub으로 구성해야 합니다.
vim /etc/default/grub
영구 메모리를 시뮬레이션하기 위해 4G 공간을 직접 구성합니다. 공간 크기가 4G임을 나타내기 위해 grub에 다음 명령문을 추가합니다. 4G 메모리에서 시작하는 메모리 공간은 영구 메모리를 시뮬레이션하는 데 사용됩니다.
GRUB_CMDLINE_LINUX=”memmap=4G!4G”
구성 후 grub을 업데이트합니다: update-grub
성공했는지 확인하려면 다음 명령을 사용하십시오.
dmesg | grep user
이 영역이 영구 메모리로 시뮬레이션되었음을 알 수 있으며, 호스트/dev 디렉터리에 pmem0 장치가 있는 것을 볼 수 있으며, 이 시점에서 시뮬레이션된 영구 메모리를 사용할 수 있습니다.
사용법–DAX 파일 시스템 생성
ext4 파일 시스템을 예로 들어 보겠습니다.
mkdir /mnt/pmemdir
mkfs.ext4 /dev/pmem0
mount -o dax /dev/pmem0 /mnt/pmemdir
이러한 방식으로 /mnt/pmem 디렉토리가 영구 메모리에 마운트되고 이 디렉토리는 이후 사용에 사용됩니다.
참조 소스: 인텔® 아키텍처 서버에서 영구 메모리를 에뮬레이트하는 방법
3.4.3 memmap 커널 옵션 사용
pmem 드라이버를 사용하면 사용자는 DAX(Direct Access File System)를 기반으로 EXT4 및 XFS를 사용할 수 있습니다. 시뮬레이션된 영구 메모리에서 사용하기 위해 하나 이상의 할당되지 않은 메모리 범위를 예약하는 것을 지원하는 새로운 memmap 옵션이 추가되었습니다. memmap 매개변수 문서는 Linux 커널의 관련 페이지에 있습니다. 이 기능은 v4.0 커널에서 위쪽으로 확장되었습니다. kernelv4.15는 성능 개선을 도입했으며 프로덕션 환경에 권장됩니다.
memmap 옵션은 memmap=nn[KMG]!ss[KMG] 형식을 사용합니다. 여기서 nn은 유지할 영역의 크기이고, ss는 시작 오프셋이며, [KMG]는 크기(킬로바이트, 메가바이트 또는 킬로바이트)를 지정합니다. ). 메가바이트 단위). 구성 옵션은 GRUB를 통해 커널에 전달됩니다. GRUB 메뉴 항목 및 커널 매개변수 변경은 Linux 배포판에 따라 다릅니다. 다음은 몇 가지 일반적인 Linux 배포판에 대한 지침입니다. 자세한 내용은 사용 중인 Linux 배포판 및 버전에 대한 설명서를 참조하세요.
메모리 영역은 e820 유형 12(0xc)로 표시되며 부팅 시 표시됩니다. dmesg 명령을 사용하여 이러한 메시지를 확인하세요.
| $ dmesg | grep e820 |
GRUB 구성의 ‘memmap=4G!12G’: 12GB에서 16GB까지 4GB 메모리를 예약합니다. 자세한 내용은 시스템에 맞는 올바른 Memmap 옵션을 선택하는 방법을 참조하세요. 각 Linux 배포판에는 GRUB 구성을 수정하는 다양한 방법이 있습니다. 배포판의 설명서를 따르십시오. 빠른 참조를 위해 아래에 몇 가지 일반적인 배포판이 제공됩니다.
1)、우분투
$ sudo vim /etc/default/grub
GRUB_CMDLINE_LINUX="memmap=4G!12G"
grub 업데이트가 완료되면 머신을 다시 시작합니다.
$ sudo update-grub2
2),RHEL
$ sudo vi /etc/default/grub
GRUB_CMDLINE_LINUX="memmap=4G!12G"
공식적으로 grub 구성 업데이트를 시작했습니다.
BIOS 기반 시스템의 경우:
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI 기반 머신의 경우:
$ sudo grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
여러 구성을 사용할 수 있으며 아래에는 두 개의 2G 네임스페이스가 설정되어 있습니다.
"memmap=2G!12G memmap=2G!14G" will create two 2GB namespaces, one in the 12GB-14GB memory address offsets, the other at 14GB-16GB.
호스트를 재부팅한 후에는 GRUB 구성에 지정된 각 memmap 영역에 하나씩 새 /dev/pmem{N} 장치가 존재해야 합니다. 이는 /dev/pmem0에서 시작하고 각 장치에 대해 증가하는 명명 규칙을 사용하여 ls /dev/pmem*을 사용하여 표시할 수 있습니다. /dev/pmem{N} 장치를 사용하여 DAX 파일 시스템을 생성할 수 있습니다.
/dev/pmem 장치를 사용하여 파일 시스템을 생성하고 탑재한 다음 탑재 지점에 dax 플래그가 설정되어 있는지 확인하여 dax 기능이 활성화되었는지 확인하세요. 다음은 EXT4 또는 XFS 파일 시스템을 생성하고 마운트하는 방법을 보여줍니다.
1) XFS
mkfs.xfs /dev/pmem0
mkdir /pmem && mount -o dax /dev/pmem0 /pmem
mount -v | grep /pmem
/dev/pmem0 on /pmem type xfs (rw,relatime,seclabel,attr2,dax,inode64,noquota)
2), EXT4
mkfs.ext4 /dev/pmem0
mkdir /pmem && mount -o dax /dev/pmem0 /pmem
mount -v | grep /pmem
/dev/pmem0 on /pmem type ext4 (rw,relatime,seclabel,dax,data=ordered)
시스템에 맞는 올바른 memmap 옵션을 선택하는 방법
memmap 커널 매개변수 값을 선택할 때 시작 주소와 끝 주소가 사용 가능한 RAM을 나타낸다는 점을 고려해야 합니다. 예약된 메모리를 사용하거나 겹치면 손상되거나 정의되지 않은 동작이 발생할 수 있습니다. 이 정보는 e820 테이블의 dmesg를 통해 쉽게 확인할 수 있습니다.
아래 예제 서버에는 16GiB의 메모리가 있으며, “사용 가능한” 메모리는 4GiB(0x100000000)에서 ~16GiB(0x3ffffffff) 사이입니다.
$ dmesg | grep BIOS-e820
[0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bffdffff] usable
[0.000000] BIOS-e820: [mem 0x00000000bffe0000-0x00000000bfffffff] reserved
[0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000003ffffffff] usable
4GiB와 16GiB 사이의 12GiB 여유 공간을 시뮬레이션된 영구 메모리로 예약하려면 구문은 다음과 같습니다.
memmap=12G!4G
새로운 사용자 정의 e820 테이블 항목 표시 범위를 다시 시작한 후 이제 “영구(type12)”가 됩니다.
$ dmesg | grep user:
[0.000000] user: [mem 0x0000000000000000-0x000000000009fbff] usable
[0.000000] user: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[0.000000] user: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[0.000000] user: [mem 0x0000000000100000-0x00000000bffdffff] usable
[0.000000] user: [mem 0x00000000bffe0000-0x00000000bfffffff] reserved
[0.000000] user: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[0.000000] user: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[0.000000] user: [mem 0x0000000100000000-0x00000003ffffffff] persistent (type 12)
fdisk 또는 lsblk 프로그램을 사용하여 용량을 표시할 수 있습니다. 예를 들면 다음과 같습니다.
# fdisk -l /dev/pmem0
Disk /dev/pmem0: 12 GiB, 12884901888 bytes, 25165824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
# lsblk /dev/pmem0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
pmem0 259:0 0 12G 0 disk /pmem
참고: 대부분의 Linux 배포판에는 CONFIG_RANDOMIZE_BASE에 정의된 KASLR(Kernel Address Space Layout Randomization)이 활성화되어 있습니다. 활성화되면 커널은 경고 없이 이전에 영구 메모리용으로 예약된 메모리를 사용하여 손상이나 정의되지 않은 동작을 일으킬 수 있으므로 16GiB 이하 시스템에서는 KASLR을 비활성화하는 것이 좋습니다. 배포판마다 다르므로 자세한 내용은 해당 Linux 배포판 설명서를 참조하세요.
4. 참고자료
Linux 가상 파일 시스템 소개
- 영구 메모리
영구 메모리 문서
차세대 스토리지 기술 개척: NVDIMM을 이해하십니까(1부)
차세대 스토리지 기술의 선두주자, NVDIMM을 이해하고 계시나요(2부)
- NVMe는 PCIe 기반 SSD를 위한 확장 가능한 고성능 호스트 컨트롤러 인터페이스입니다.
- NVMe의 특징은 I/O 명령을 처리하기 위한 여러 대기열을 제공한다는 것입니다. 단일 NVMe 장치는 최대 64K I/O 대기열을 지원하고 각 I/O 대기열은 최대 64K 명령을 관리할 수 있습니다.
- 호스트가 I/O 명령을 내리면 호스트 시스템은 명령을 제출 대기열(SQ)에 넣은 다음 초인종 레지스터(DB)를 사용하여 NVMe 장치에 알립니다.
- NVMe 장치가 I/O 명령 처리를 완료하면 장치는 처리 결과를 완료 대기열(CQ)에 쓰고 인터럽트를 트리거하여 호스트 시스템에 알립니다.
- NVMe는 MSI/MSI-X 및 인터럽트 집계를 사용하여 인터럽트 처리 성능을 향상시킵니다.
2. SPDK 개요
Storage Performance Development Kit(SPDK)는 확장 가능한 고성능 사용자 모드 스토리지 응용 프로그램을 작성하기 위한 일련의 도구 및 라이브러리 기능을 제공합니다. SPDK가 고성능을 낼 수 있는 이유는 필요한 모든 드라이버를 사용자 공간으로 옮겨 실행하고, 인터럽트 모드 대신 폴링 모드를 사용함으로써 커널 컨텍스트 전환을 피하고 인터럽트 처리 오버헤드를 제거하기 때문입니다.
SPDK의 기반은 사용자 공간, 폴링 모드, 비동기식, 잠금 없는 NVMe 드라이버입니다. 사용자 공간 애플리케이션은 SSD 디스크에 직접 액세스할 수 있으며 무복사, 고도의 병렬 방식으로 SSD 디스크에 액세스할 수 있습니다. 드라이버는 단일 공용 헤더 파일을 포함하는 C 라이브러리로 구현됩니다. 마찬가지로 SPDK는 NVMe 드라이버의 모든 특성을 가진 많은 Intel Xeon 기반 플랫폼에 있는 I/OAT DMA 엔진용 사용자 공간 드라이버를 제공합니다.
또한 SPDK는 또한 이러한 사용자 공간 드라이버 위에 구축된 NVMe-oF 및 iSCSI 서버를 제공하여 네트워크 디스크를 서비스할 수 있도록 합니다. 클라이언트는 표준 Linux 커널 iSCSI 및 NVMe-oF 이니시에이터(또는 Windows의 iSCSI 이니시에이터)를 사용하여 서버에 연결할 수 있습니다. 이러한 서버는 다른 구현에 비해 CPU 사용률을 훨씬 향상시킬 수 있습니다.
SPDK는 C 라이브러리와 실행 파일을 통합하는 오픈 소스 BSD 라이센스 개발 키트이며 해당 소스 코드는 GitHub에서 호스팅됩니다. 모든 새로운 개발은 마스터 브랜치에 적용되며 안정적인 버전은 분기마다 릴리스됩니다. 코드 기여자와 사용자는 메일링 리스트를 통해 패치를 제출하고, 문제를 보고하고, 질문할 수 있습니다.
3. SPDK/NVMe 드라이버 개요
NVMe 드라이버는 응용 프로그램과 NVMe SSD 간에 복사 없이 직접 데이터 전송을 제공하기 위해 응용 프로그램에 직접 연결할 수 있는 C 함수 라이브러리입니다. 이것은 완전히 수동적입니다. 스레드를 생성하지 않고 애플리케이션 자체의 함수 호출에 대한 응답으로만 작업을 수행합니다. 이 라이브러리는 PCI BAR 레지스터를 로컬 프로세스에 직접 매핑한 다음 MMIO(메모리 매핑된 I/O)를 수행하여 NVMe 장치를 직접 제어합니다. I/O는 대기열 쌍(Queue Pair)을 통해 비동기적으로 제출되며 일반적인 실행 흐름은 Linux의 libaio와 완전히 다르지 않습니다.
자세한 내용은 여기를 참조하십시오 .
4. 기타 NVMe 드라이버 구현
- Linux 커널 NVMe 드라이버: 공식 웹사이트 www.kernel.org 또는 미러로 이동 하여 커널 소스 코드를 다운로드한 다음 include/linux/nvme.h, drivers/nvme를 참고하십시오.
- NVMeDirect : Computer Systems Laboratory@SKKU에서 시작한 오픈 소스 프로젝트로 SPDK/NVMe 드라이버와 유사하지만 Linux 커널 NVMe 드라이버를 기반으로 하고 있습니다. NVMeDirect는 거인의 어깨 위에 서 있는 사용자 모드 I/O 프레임워크라고 할 수 있습니다.