블록 크기가 작을 때 왜 내 dd가 그렇게 느린가요?

블록 크기가 작을 때 왜 내 dd가 그렇게 느린가요?

온라인 기사에 따르면 다음을 사용하여 마운트하면 nobarrier디스크 속도가 빨라집니다.

  1. img에 작은 데이터 덩어리를 씁니다(사용 barrier).느린

    # dd if=/dev/zero of=xfs.img bs=1024 count=20000
    # mkfs.xfs xfs.img
    # mkdir -p xfs
    # mount -o loop xfs.img xfs
    # dd if=/dev/zero of=output bs=32K count=1 conv=fsync
    32768 bytes (33 kB) copied,0.01037167 s, 2.4 MB/s
    
  2. -o nobarrierimg( ) 에 작은 데이터 덩어리를 씁니다 .빠르게

    # dd if=/dev/zero of=xfs.img bs=1024 count=20000
    # mkfs.xfs xfs.img
    # mkdir -p xfs
    # mount -o loop,nobarrier xfs.img xfs
    # cd xfs ; dd if=/dev/zero of=output bs=32K count=1 conv=fsync
    32768 bytes (33 kB) copied, 0.000608567 s, 53.8 MB/s
    

이제 플래그를 /추가하기 위해 다시 설치하고 싶습니다 . nobarrier그래서 편집했습니다 /etc/fstab:

/dev/sda2      /      xfs     defaults,nobarrier    0    0

그 다음에 mount -o remount /.

그러나 결과는 좋지 않습니다:

# pwd
/root
# dd if=/dev/zero of=output bs=32K count=1 conv=fsync
32768 bytes (33 kB) copied, 0.00811443 s, 4.0 MB/s

nobarrierdd-img에서는 작동하지만 기존 파티션에서는 작동하지 않는 이유를 이해할 수 없습니다 . 누구든지 말해 줄 수 있나요?

답변1

루프백 파일 시스템을 사용하는 경우 루프백이 생성된 파일 시스템을 고려해야 합니다. 특히 루프백 파일 시스템에서 fsync가 호출되었음에도 불구하고 커널은 루프백 파일 시스템의 쓰기 페이지를 파일 시스템이 포함된 디스크에 즉시 플러시하지 않을 수 있습니다. 이러한 쓰기는 sync루프백에서 발생할 수 있지만 파일 시스템을 포함하는 메모리의 더티 페이지로 발생할 수 있습니다.

이제 nobarrier이 옵션이 루프백 드라이버 및 포함된 파일 시스템과 어떻게 상호 작용하는지 잘 모르겠습니다. 그래서 실험을 해봤습니다. 포함하는 파일 시스템을 마운트하기 위해 변수를 추가했습니다 sync. 결과는 다음과 같습니다.

(모든 출력은 dd if=/dev/zero of=xfs/output bs=32K count=10000 conv=fsync)

  1. asyncfs , 루프백 포함barrier

    32768000 bytes (33 MB) copied, 0.401873 s, 81.5 MB/s
    
  2. asyncfs , 루프백 포함nobarrier

    32768000 bytes (33 MB) copied, 0.0414423 s, 791 MB/s
    
  3. syncfs , 루프백 포함barrier

    32768000 bytes (33 MB) copied, 71.5749 s, 458 kB/s
    
  4. syncfs , 루프백 포함nobarrier

    32768000 bytes (33 MB) copied, 70.6415 s, 464 kB/s
    

fs가 포함되면 barrier총 속도가 크게 변경됩니다. 그러나 포함하는 파일 시스템이 페이지 캐싱의 이점을 누리고 페이지 캐싱의 이점을 얻지 못하는 경우 속도 향상이 대부분 손실됩니다.nobarrierasyncsync

결론은 루프백 파일 시스템을 테스트 barrier하고 사용하는 것이 도움이 되지 않는다는 것입니다. nobarrier파일 시스템 및 커널 캐시와 관련된 상호 작용이 차단됩니다. 루프백을 사용하여 성능을 테스트할 때 잘못된 결과를 초래하는 유일한 요인은 커널 캐시가 아닌 것 같습니다.

답변2

Linux에서는 이러한 가정에 주의하세요. Linux는 실제 속도를 최적화하기보다는 파일 시스템이 빠르다는 인상을 주도록 최적화되어 있습니다.

고속이라는 인상을 주는 이유는 쓰기 프로그램이 완료될 때 파일 데이터가 (많은 경우) 디스크에 없기 때문입니다. 즉, 당신은 말할 수 없습니다측정 대상dd가 완료된 후 파일 시스템 상태를 모르기 때문에 테스트하십시오.

비교 가능한 결과를 얻으려면 지정된 문제에 영향을 받지 않는 성능 테스트를 설정해야 하므로 컴퓨터 로컬 RAM 크기의 최소 2배 이상인 파일을 작성해야 합니다.

관련 정보