사랑에 빠졌다리눅스 시스템 프로그래밍, 3장 버퍼링된 I/O
블록은 파일 시스템에서 가장 작은 저장 단위를 나타내는 추상화라는 점을 1장에서 상기해 보세요. 커널 내부에서는 모든 파일 시스템 작업은 블록 단위로 발생합니다.. 실제로 블록은 I/O의 보편적 언어입니다. 따라서 블록 크기보다 작거나 블록 크기의 배수가 아닌 데이터 양에 대해서는 I/O 작업을 수행할 수 없습니다. 단일 바이트만 읽고 싶다면 안타깝습니다. 전체 블록을 읽어야 합니다. 4.5블록의 데이터를 쓰고 싶으십니까? 5개의 블록을 써야 합니다. 즉, 전체 블록을 읽고 변경된 절반만 업데이트한 다음 전체 블록을 다시 쓰는 것을 의미합니다.
이것이 어디로 가는지 알 수 있습니다. 부분 블록 작업은 비효율적입니다. 운영 체제는 모든 것이 블록 정렬 경계에서 발생하고 다음으로 가장 큰 블록으로 반올림되도록 하여 I/O를 "수정"해야 합니다. 불행하게도 이는 사용자 공간 애플리케이션이 일반적으로 작성되는 방식이 아닙니다. 대부분의 애플리케이션은 크기가 블록 크기와 무관한 필드 및 문자열과 같은 더 높은 수준의 추상화 측면에서 작동합니다. 최악의 경우, 사용자 공간 애플리케이션은 한 번에 1바이트만 읽고 쓸 수 있습니다! 이것은 엄청난 낭비입니다. 각 단일 바이트 쓰기는 실제로 전체 블록을 씁니다.
사용자 버퍼 I/O
일반 파일에 대해 많은 작은 I/O 요청을 발행해야 하는 프로그램은 종종 사용자 버퍼 I/O를 수행합니다. 이는 커널에 의해 수행되는 버퍼링과 달리 애플리케이션에 의해 수동으로 또는 라이브러리에서 투명하게 사용자 공간에서 수행되는 버퍼링을 나타냅니다. 2장에서 설명한 것처럼 성능상의 이유로커널은 쓰기를 연기하고, 인접한 I/O 요청을 통합하고, 미리 읽어 데이터를 내부적으로 버퍼링합니다.. 다양한 방식으로 사용자 버퍼링도 성능을 향상시키도록 설계되었습니다.
사용자 공간 프로그램 dd를 사용하는 예를 생각해 보세요.
dd bs=1 count=2097152 if=/dev/zero of=piratebs=1 매개변수로 인해 이 명령은 장치 /dev/zero(무제한 제로 스트림을 제공하는 가상 장치)에서 파일 불법 복제로 2,097,152개의 단일 바이트 블록에 2MB를 복사합니다. 즉, 약 200만 개를 통해 데이터를 복사하게 됩니다.읽기 및 쓰기 작업-- 한 번에 1바이트입니다.
이제 동일한 2MB 복사본을 고려하지만 1,024바이트 블록을 사용합니다.
dd bs=1024 count=2048 if=/dev/zero of=pirate이 작업은 동일한 2MB를 동일한 파일에 복사하지만 문제가 1,024배 더 적게 발생합니다.읽기 및 쓰기 작업. 표 3-1에서 볼 수 있듯이 성능 향상이 엄청납니다. 여기서는 블록 크기만 다른 4개의 dd 명령으로 측정한 시간(3가지 다른 측정값 사용)을 기록합니다. 실시간은 총 벽시계 시간이고, 사용자 시간은 사용자 공간에서 프로그램 코드를 실행하는 데 소요된 시간이며, 시스템 시간은 커널 공간에서 시스템 호출을 실행하는 프로세스에 소요된 시간을 나타냅니다.
표 3-1. 블록 크기가 성능에 미치는 영향
Block size Real time User time System time 1 byte 18.707 seconds 1.118 seconds 17.549 seconds 1,024 bytes 0.025 seconds 0.002 seconds 0.023 seconds 1,130 bytes 0.035 seconds 0.002 seconds 0.027 seconds1,024바이트 블록을 사용하면 단일 바이트 블록에 비해 성능이 크게 향상됩니다. 그러나 표에도 나와 있습니다.디스크 블록 크기의 배수로 작업을 수행하지 않는 경우 더 큰 블록 크기(시스템 호출 수가 적음)를 사용하면 성능이 저하될 수 있습니다..더 적은 호출이 필요하기는 하지만 1,130바이트 요청은 결국 정렬되지 않은 요청을 생성하게 되므로 1,024바이트 요청보다 효율성이 떨어집니다.
이러한 성능 향상을 활용하려면 물리적 블록 크기에 대한 사전 지식이 필요합니다. 표의 결과는 블록 크기가 1,024, 1,024의 배수 또는 1,024의 제수일 가능성이 있음을 보여줍니다. /dev/zero의 경우 블록 크기는 실제로 4,096바이트입니다.
"더 적은 수의 호출이 필요함에도 불구하고 1,130바이트 요청이 결국 정렬되지 않은 요청을 생성하게 되어 1,024바이트 요청보다 효율성이 떨어지는" 이유는 무엇입니까? (1024바이트 요청으로 성능이 다른 이유는 무엇입니까?)
발행된 시스템 호출 수 와
count의 비율은 무엇입니까 ?bsdd"읽기 및 쓰기 작업" 횟수는 어떻게 결정되나요?
"커널이 쓰기 연기, 인접한 I/O 요청 통합 및 미리 읽기를 통해 내부적으로 데이터를 버퍼링"하는 경우 사용자 버퍼가 필요한 이유는 무엇입니까? 커널 버퍼는 이미 사용자 버퍼가 수행하는 작업을 수행하지 않습니까?
"파일 시스템 작업이 블록에서 발생합니다"는 작업이 블록 또는 블록의 정수배에서 발생한다는 것을 의미합니까?
감사해요.
답변1
"더 적은 수의 호출이 필요함에도 불구하고 1,130바이트 요청이 결국 정렬되지 않은 요청을 생성하게 되어 1,024바이트 요청보다 효율성이 떨어지는" 이유는 무엇입니까?
개념적 모델을 제공하겠습니다. 이 문제를 줄이는 일부 최적화가 커널에 있을 수 있습니다(하지만 완전히 사라지지는 않습니다).
블록 크기가 1024이면 일련의 블록이 생성됩니다.
[1, 1024], [1025, 2048], [2049, 3076], [3077, 4096], ...
1130의 블록 크기가 기록되면 write()시스템 호출에 대한 첫 번째 호출은 하나의 요청을 충족하기 위해 두 개의 디스크 블록을 작성해야 합니다. 먼저 처음 1024바이트를 블록에 쓰고 [1, 1024]106바이트를 쓰지 않은 상태로 둡니다. 그런 다음 두 번째 블록( [1025, 2048])을 읽고 나머지 106바이트를 블록의 처음 106바이트에 복사한 다음 블록을 다시 디스크에 씁니다.
시스템 호출에 대한 다음 호출은 write()두 번째 블록을 다시 읽고( [1025, 2048]) 블록의 바이트에 기록할 1130바이트 중 처음 918바이트(1024-106)를 복사한 [1131, 2048]다음 블록을 디스크에 다시 복사해야 합니다. 그런 다음 세 번째 블록( [2049, 3076])을 읽고 1130의 마지막 212바이트를 블록의 처음 212바이트에 쓴 다음 해당 블록을 다시 디스크에 씁니다.
이 패턴은 계속됩니다. 비록 더 적은 호출에도 불구하고 write()커널은 기존 블록에 단순히 쓰는 대신 기존 블록을 반복적으로 읽고/업데이트/쓰기해야 합니다.
s를 블록 크기에 맞춰 정렬하면 write()"청크 읽기, 일부 업데이트, 다시 쓰기" 상황이 발생하지 않으며 청크를 쓰고 계속 진행할 수 있으며 읽기/업데이트할 필요가 없습니다. 쌍을 만족시키기 위한 동일한 청크 write().
"커널이 쓰기 연기, 인접한 I/O 요청 통합 및 미리 읽기를 통해 내부적으로 데이터를 버퍼링"하는 경우 사용자 버퍼가 필요한 이유는 무엇입니까? 커널 버퍼는 이미 사용자 버퍼가 수행하는 작업을 수행하지 않습니까?
사용자 공간은 커널 공간 버퍼에 직접 액세스할 수 없습니다. 사용자 공간 버퍼는 프로그램이 모든 바이트에 대해 시스템 호출을 하지 않고 "청크"를 읽을 수 있도록 하는 데 필요합니다(Love가 보여준 것처럼 비효율적임).
"파일 시스템 작업이 블록에서 발생합니다"는 작업이 블록 또는 블록의 정수배에서 발생한다는 것을 의미합니까?
저장 장치와 통신하는 데 사용되는 장치 및 프로토콜에 따라 다르다고 생각합니다.