저는 순수한 Linux 시스템을 사용하고 있으므로 사용 가능한 비지박스 구현도 자체적인 busybox 1.27
것도 없습니다 .output=progress
pv
pipe_progress
pv
두 가지 질문이 있습니다. 첫 번째는 다음을 기반으로합니다.https://www.linux.com/training-tutorials/show-progress-when-using-dd/. USR1
신호를 보내 dd
프로세스를 "일시 중지"하고 dd
현재 상태를 인쇄한 후 수행 중인 작업을 계속한다고 말합니다 . 운영에 미치는 영향을 최소화 dd
하기 위해 벤치마킹을 수행하려고 합니다 . 전달되는 데이터가 변동하고 전송 속도가 떨어지는 시기를 식별하는 것이 중요하기 때문에 dd
매초마다 현재 작업의 출력을 얻고 싶습니다.dd
첫 번째 질문: "dd"는 신호를 받을 때마다 "일시 중지"됩니다. 이것이 사실입니까 USR1
?
1초마다 일시정지 하면 dd
수십 기가바이트를 전송할 때 작업 시간이 늘어납니다.
두 번째 질문: 가설예첫 번째 질문에 대한 답변으로, 프로세스에 신호를 보내지 않고 프로세스의 현재 상태를 인쇄할 수 있는지 궁금합니다 dd
. 일종의 리디렉션 STDOUT
(예: 2>&1)이 아닐까요?
내 말은:
# bs with 1Mib so I can have more control on the test.
dd if=/dev/zero of=/dev/null bs=1048576 count=1024
# Printing current operation status.
sudo kill -USR1 $dd_pid
답변1
dd if=/dev/zero of=/dev/null bs=1048576 count=1024
알아채다dd
데이터를 파괴할 수 있음, 적어도bs
매개변수를 사용하는 경우. 그리고성능상의 이점특정 시스템 구성에 대한 최적의 블록 크기를 수동으로 선택하는 경우 기껏해야 아주 작습니다. cat
또는 cp
더 잘 수행할 수 있지만 기껏해야 약간 더 느릴 수 있습니다. 따라서 dd
꼭 필요하지 않다면 사용하지 마세요.
버전 1.23부터 BusyBox는 다음을 사용합니다.sendfile
read
및 를 사용하는 대신 데이터를 복사하는 시스템 호출입니다 write
. 하지만 :, : cat
등의 일반 복사본 만 cp
/를 사용해야 하는데, 크기에 대한 정밀한 제어가 필요하기 때문입니다 . 따라서 BusyBox ≥1.23 이며 .sendfile
dd
read
write
cat
cp
dd
'dd'는 USR1 신호를 수신할 때마다 "일시 중지"됩니다. 이것이 사실입니까?
기술적으로는 그렇습니다. 신호를 처리하려면 "일시 중지"해야 합니다. 그러나 일시 중지는 몇 가지 CPU 명령만 수행하면 됩니다(가장 비용이 많이 드는 부분은 진행률 출력을 인쇄하는 것입니다). 따라서 이것은 어떤 식으로든 벤치마크를 무효화하지 않습니다.
dd가 1초마다 일시 중지되면 수십 기가바이트의 데이터를 전송할 때 작업 시간이 늘어납니다.
아니요, 규모 순서가 잘못되었습니다. 단일 CPU 스레드에 0.1%의 시간을 추가할 수 있습니다. 주요 비용은 벤치마크의 커널 시간이므로 dd
구현 방법이 아니라 수행하려는 작업에 내재된 것이 아닙니다.
프로세스에 신호를 보내지 않고 dd가 현재 상태를 인쇄하도록 할 수 있습니까?
음 ... 아니. 이를 수행하는 간단하고 역사적으로 확립된 표준적이고 쉬운 방법이 이미 있습니다. 구현하기 더 어려운 다른 방법이 있는 이유는 무엇입니까?
Linux에서는 복제본이 도달한 지점을 알 수 있는 일반적인 방법이 있습니다. 특수 파일에 대해 항상 작동하는 것은 아니지만 복사를 수행하는 프로그램에 따라 달라지지는 않습니다. $pid
복사를 수행하는 프로세스 ID와 입력 및 출력에 사용되는 파일 설명자를 알아보세요 . dd
fd 0에서 읽고 fd 1에 씁니다. BusyBox는 cp
일반적으로 fd 3에서 읽고 fd 4에 씁니다. .NET의 심볼릭 링크를 통해 어떤 파일 설명자에 어떤 파일이 열려 있는지 확인할 수 있습니다 /proc/$pid/fd
.
$ cp /dev/zero /dev/null & pid=$!
$ readlink /proc/$pid/fd/3
/dev/zero
$ readlink /proc/$pid/fd/4
/dev/null
$n$
파일 설명자 에서 위치를 확인할 수 있습니다 /proc/$pid/fd/$n
.
$ cat /proc/$pid/fdinfo/4
pos: 74252288
flags: 0100001
mnt_id: 27
그러나 파일 설명자 위치는 /dev/zero
, 파이프 또는 소켓과 같은 특수 파일로 /dev/null
업데이트 되지 않을 수 있습니다. 항상 일반 파일을 사용하여 업데이트됩니다. 블록 장치용으로 업데이트되었는지는 모르겠습니다. 따라서 /dev/zero
및 사이의 복사에 대한 정보를 제공하지 않을 수도 있지만 /dev/null
실제 사용 사례에서는 작동할 수 있습니다.
답변2
인터페이스를 통해서도 진행 상황을 확인할 수 있습니다 /proc
.
# dd bs=1M if=/dev/mmcblk0 of=/dev/null &
# pidof dd
1358
따라서 이 프로세스에 대한 정보는 다음에서 확인할 수 있습니다 /proc/1358
.
# ls -l /proc/1358/fd
total 0
lr-x------ 1 root root 64 Nov 2 09:16 0 -> /dev/mmcblk0
l-wx------ 1 root root 64 Nov 2 09:16 1 -> /dev/null
lrwx------ 1 root root 64 Nov 2 09:16 2 -> /dev/pts/0
파일 핸들 0은 입니다 if=/dev/mmcblk0
. 현재 진행 상황은 어디입니까?
# cat /proc/1358/fdinfo/0
pos: 2132803584
flags: 0400000
mnt_id: 17
# cat /proc/1358/fdinfo/0
pos: 2366636032
flags: 0400000
mnt_id: 17
# cat /proc/1358/fdinfo/0
pos: 2587885568
flags: 0400000
mnt_id: 17
이렇게 하면 busybox dd의 경우 fdinfo pos 값에서 진행 상황을 얻을 수도 있습니다.
즉, USR1 신호를 적당히 보내는 것은 성능에 거의 영향을 미치지 않습니다. 리소스가 거의 없는 임베디드 시스템에서 fdinfo를 폴링하면 비슷한 효과가 있을 수 있습니다.