원시 장치에서는 쓰기가 느리지만 파일 시스템(USB 키)에서는 쓰기가 빠른 이유는 무엇입니까?

지금 다시 보니 하드 드라이브가 아니라 USB 키(플래시 드라이브)라고 말씀하셨군요. 플래시 메모리는 큰 덩어리로만 지울 수 있으며 개별 섹터는 먼저 해당 섹터(및 해당 섹터가 포함된 전체 블록)를 지우지 않고는 쓸 수 없습니다. 소프트웨어는 언제든지 디스크에 원하는 내용을 쓸 수 있기를 원하므로 삭제를 투명하게 처리하기 위한 변환 논리가 디스크에 있습니다. 이를 수행하는 방법은 쓰기 성능에 큰 영향을 미칠 수 있습니다. 많은 장치는 순차 쓰기를 잘 처리하지만 무작위 쓰기에는 좋지 않은 알고리즘을 대부분의 디스크에 사용합니다. 디스크 시작 부분 근처의 영역은 일반적으로 미리 포맷된 FAT 파일 시스템에서 FAT에 의해 사용되며 이 영역은 무작위로 기록되는 경우가 많기 때문에 이 영역에 대해 다른 알고리즘을 사용합니다. 이는 순차적으로 기록할 때 속도가 느리지만 무작위 쓰기가 나쁜 것은 아닙니다. .

그래서 나는 이제 내가 코멘트로 추가한 초기 추측이 정확했다고 확신합니다. 파일 시스템에 쓸 때 디스크의 나머지 부분의 성능을 살펴보고, 오프셋 0에서 dd를 수행하면 뚱뚱한 영역에 쓰는 것입니다. 수백 MB의 추가 대상을 찾고 있다면 속도가 상당히 빨라질 것입니다.

측정값은 커널 아키텍처로 설명할 수 있습니다. 파일 시스템 액세스를 사용하면 커널의 잠재력과 커널이 수행할 수 있는 모든 버퍼 및 최적화의 잠금이 해제됩니다. 특히 버퍼는 벤치마크 속도를 높여줍니다(커널은 100% a_A_syncronous입니다). 장치 파일의 dd는 그 중 일부 또는 대부분을 사용하지 않습니다.

hdparm캐싱을 사용하거나 사용하지 않고 드라이브 성능을 벤치마킹 해 보세요 .

$ sudo hdparm -tT /dev/sda1

/dev/sda1:
 Timing cached reads:   6314 MB in  2.00 seconds = 3157.61 MB/sec
 Timing buffered disk reads: 244 MB in  3.04 seconds =  80.26 MB/sec

이는 쓰기 최적화로 인해 발생합니다.스파스 파일파일 시스템에서.

dd if=/dev/zero원시 장치로 이 작업을 수행 하면 실제로 디스크에 0개의 블록이 기록됩니다.

그러나 이를 파일에 쓰면 파일 시스템은 데이터 쓰기를 무시하고 메타데이터만 저장합니다. 이로 인해 디스크에 기록되는 블록이 거의 없습니다. 파일은 내부에 아무것도 없는 큰 구멍으로 볼 수 있습니다.

이런 방식으로 성능을 테스트하려면 다음을 사용하세요./dev/urandom입력 파일로 ( dd if=/dev/urandom). 이렇게 하면 파일 시스템이 디스크에 임의의 데이터를 쓰게 됩니다.