Linux에서 파일 캐싱을 위한 최적의 블록 크기는 얼마입니까?

Linux에서 파일 캐싱을 위한 최적의 블록 크기는 얼마입니까?

장치 블록 크기는 일반적으로 512바이트이고 파일 시스템 블록 크기는 일반적으로 4096바이트입니다. 왜 다른가요? 장치 및 파일 시스템 블록 크기에 512B 및 4KB를 선택하는 것이 좋은 이유는 무엇입니까? 사용자 공간 라이브러리에서 디스크 읽기를 캐싱하는 데 가장 적합한 블록 크기는 무엇입니까?

답변1

장치 블록 크기는 시스템이 HDD 컨트롤러와 통신하는 데 사용하는 블록 크기입니다. 하드 드라이브를 읽고 쓰려는 경우 다음과 같은 일이 발생합니다.

  1. 읽다:

    1. CPU -> HDD 컨트롤러: "43623626 블록의 데이터를 보내주세요."
    2. HDD 컨트롤러->CPU: "완료, 여기 있습니다: 0xfce2c0deebed..."
  2. 쓰다:

    1. CPU -> HDD 컨트롤러: "이 데이터를 블록 3452345: 0xfce2c0deebed...에 기록해 주십시오."
    2. HDD 컨트롤러->CPU: "완료"

여기서 블록 번호는 2354242번째 512바이트 블록의 이름을 나타냅니다.

이론적으로는 모든 블록 크기를 사용할 수 있습니다. 대부분의 장치는 512바이트 블록을 사용하며 일부(특히 대형 HDD)는 4096바이트 블록을 사용합니다. 일부 광 미디어는 2304바이트 블록을 사용합니다.

중요: 블록 장치 컨트롤러는 해당 파일 시스템에 대해 아무것도 모릅니다. 블록 크기만큼 미디어에 블록을 읽고 쓸 수만 있습니다. 이는 블록 장치 드라이버가 커널에 블록 장치를 제공하기 위해 사용하는 것입니다. 본질적으로 큰 바이트 배열입니다.파티션이 어떻게 분할되어 있는지, 어떤 파일 시스템이 이를 사용하고 있는지는 중요하지 않습니다.

파일 시스템 블록 크기는 파일 시스템 데이터 구조가 구성되는 파일 시스템의 블록 크기입니다. 파일시스템의 내부적인 특성이며,블록 지향 데이터 구조를 사용할 필요조차 없으며 일부 파일 시스템에서는 그렇게 하지도 않습니다..

Ext4는 가장 일반적으로 4096바이트 블록을 사용합니다.

또한 디스크 IO 데이터는 일반적으로 프로세스에서 직접 처리되지 않고 운영 체제의 가상 메모리에서 처리됩니다. 페이지 매김을 광범위하게 사용합니다. VM 페이지 크기는 일반적으로 4096바이트(x86이 아닌 CPU에 따라 다를 수 있음)이며 CPU 아키텍처에 따라 결정됩니다. (예를 들어 최신 amd64 CPU는 2MB 페이지를 처리할 수 있거나 dec alpha는 8192바이트 페이지를 사용합니다.)

데이터 IO를 최적화하려면 서로 곱하는 것이 가장 좋으며, 같으면 더 좋습니다. 이는 일반적으로 4096바이트 fs 블록을 사용한다는 의미입니다.

마찬가지로 중요한 것은 다음과 같습니다.블록 장치가 분할된 경우 파티션은 정확한 페이지 크기로 시작/끝나야 합니다.. 이렇게 하지 않으면, 예를 들어 sda1이 sda의 블록 17에서 시작하면 물리적 블록과 파일 시스템 블록이 겹치기 때문에 CPU는 모든 페이지 읽기/쓰기 작업에 대해 두 개의 읽기/쓰기 명령을 실행해야 합니다.

가장 일반적인 경우 이는 다음을 의미합니다. 모든 파티션은 8로 나눌 수 있는 섹터(4096 / 512 = 8)에서 시작하거나 시작해야 합니다.

일반적으로 낮은 수준의 블록 IO는 단일 블록 읽기/쓰기 작업에서는 발생하지 않지만 단일 명령으로 여러 블록이 전송/수신됩니다. 메모리 IO는 일반적으로 블록 장치 IO보다 훨씬 빠르기 때문에 데이터 재구성은 일반적으로 큰 오버헤드가 아닙니다. 따라서 이를 따르지 않아도 상당한 오버헤드가 발생하지 않습니다.

관련 정보