ddrescue가 전체 대역폭을 활용하지 않는 이유는 무엇입니까?

ddrescue가 전체 대역폭을 활용하지 않는 이유는 무엇입니까?

ddrescueA드라이브에서 B드라이브로 이동했습니다 .

나는 더 느린 디스크가 항상 최고 속도로 실행되고 다른 디스크가 이를 따라잡기에 충분할 것이라고 생각했을 것입니다.

vmstat 5(즉, 아래 숫자는 5초 평균임) 다음과 같은 결과가 나왔을 때 놀랐던 점을 상상해 보십시오.

procs -----------memory----------    ---swap-- -----io----      -system--    -----cpu-----
 r b  swpd   free   buff     cache   si so     bi     bo        in   cs      us sy id wa st
 2 0  608260 234672 21308688 4346420 0  0      116890 31        1374 2884    1  4  85 10 0
 0 1  608260 232820 21309700 4348712 0  0      134248 53        1546 3354    1  4  85 10 0
 3 1  608260 247120 21267028 4374552 0  0      134272 0         2162 5534    4  4  83 9  0
 1 2  608260 244292 21265720 4374092 0  0      134246 139792    2518 5139    4  7  71 19 0
 0 2  608260 244480 21224808 4417508 0  0      64845  129203    1726 7227    3  5  72 20 0
 0 2  608260 247056 21224816 4414024 0  0      0      106422    850  1089    1  3  74 22 0
 0 2  608260 239648 21224824 4418628 0  0      0      111522    920  1455    2  3  75 21 0
 2 1  608260 291152 21224852 4377064 0  0      0      97719     984  1407    3  3  72 22 0
 0 1  608260 230956 21312888 4351932 0  0      99738  21        1264 3855    1  3  85 11 0
 0 1  608260 244772 21297528 4353928 0  0      131123 16        1451 3080    1  4  86 9  0
 1 0  608260 254376 21263872 4378864 0  0      62694  84199     1202 1989    2  4  86 8  0
 0 1  608260 250532 21263896 4382276 0  0      0      139168    954  974     1  3  88 8  0
 0 1  608260 242984 21297132 4355128 0  0      21710  70264     925  1487    1  2  90 7  0
 0 1  608260 224980 21310664 4359112 0  0      129997 29        1498 3221    1  4  85 10 0
 0 2  608260 237668 21270804 4387544 0  0      129997 106189    1848 3093    1  6  79 14 0
 1 1  608260 228084 21303840 4365168 0  0      129997 100277    1944 3129    1  6  75 18 0
 0 2  608260 245196 21227500 4424640 0  0      62643  84207     1220 5027    1  4  83 11 0
 0 2  608256 259756 21227516 4408504 0  0      0      87639     972  10750   1  3  73 22 0
 0 2  608248 236968 21227524 4429560 0  0      0      96103     955  9584    1  3  73 23 0
 0 1  608248 241404 21283160 4371248 0  0      78541  42        1186 3315    2  3  85 11 0
 1 1  608244 248900 21263160 4373180 0  0      129998 44        1595 4237    3  4  82 11 0
 0 1  608192 229964 21212448 4390868 6  0      130147 75        2490 9510    9  5  74 12 0
 0 1  608192 247132 21177192 4409944 0  0      62738  78208     1297 2931    1  4  86 9  0

따라서 우리가 볼 수 있는 것은 디스크 A가 한동안 최고 속도로 실행되다가 거의 즉시 중단되고, 디스크 B가 최고 속도로 실행되기 시작하며, 중단되면 디스크 A가 다시 작동한다는 것입니다.

ddrescue2GB 버퍼가 있다면 2GB를 읽고 2GB를 쓰고 반복하는 것이 합리적입니다. 하지만 그렇지 않습니다. 약 2MB의 RAM을 차지합니다.

또한 "시간 버퍼"일 수도 있으므로 20-30초 동안 읽은 다음 20-30초 동안 씁니다. 그러나 다시 말하지만, 나는 ddrescue그런 일을 하라는 요청을 받지 않으며 메모리 사용량은 ddrescue동일하게 유지됩니다.

디스크 읽기가 중지되면 ddrescue화면이 업데이트되지 않습니다. 읽기가 다시 시작될 때만 화면이 업데이트됩니다 ddrescue. 그러나 지속적으로 CPU 시간의 20%를 소비합니다.

그렇지 않으면 시스템이 유휴 상태(때때로 1MB/s의 속도로 루트 디스크로 이동)이고 A 드라이브나 B 드라이브가 마운트되지 않습니다.

여기서 볼 수 있는 내용은 느린 디스크가 항상 100% 활용률로 실행되지 않는 이유는 무엇입니까?

편집하다

단지 재미를 위해 나는 dd다음을 ddrescue시도 했습니다 cat.

dd if=/dev/sdc of=/dev/sdf bs=64k
cat /dev/sdc >/dev/sdf

결과는 거의 동일합니다. 이는 vmstat 5내가 기대했던 결과를 더 많이 제공하기 때문입니다. 쓰기 디스크가 상태로 전환되는 데 시간이 좀 걸리지만 읽기 디스크와 동일한 속도로 씁니다( cat쓰기 디스크는 훨씬 더 빠르게 상태로 들어갑니다).

procs -----------memory----------   ---swap-- -----io----     -system-- ------cpu-----
 r b swpd   free   buff     cache   si so     bi     bo       in   cs   us sy id wa st
 1 2 606928 245344 20762212 4440244 0  0      130662 26235    1727 3460 1  5  83 12 0
 1 1 606928 244132 20762812 4439672 0  0      130637 123438   2146 3380 1  7  73 19 0
 0 2 606928 227948 20805904 4412948 0  0      130662 30634    1741 3282 1  5  83 12 0
 0 2 606928 235468 20770744 4438160 0  0      129024 115610   2040 3374 1  6  75 17 0
 0 2 606928 243064 20766380 4439116 0  0      128691 131280   2129 3343 1  7  74 18 0
 0 1 606928 233528 20800160 4413956 0  0      128691 67756    1966 3434 1  6  78 16 0
 0 2 606928 230792 20775552 4438440 0  0      128666 69637    1974 4296 3  5  79 13 0
 0 2 606928 254492 20752076 4437996 0  0      127693 133437   2209 3595 1  7  73 18 0
 3 0 606928 233820 20767232 4440488 0  0      127693 137047   2335 5781 4  6  71 19 0
 1 1 606928 232712 20796324 4414648 0  0      127693 88403    2147 3568 1  6  77 16 0
 0 2 606928 226688 20772316 4442504 0  0      127181 141011   2255 3552 1  7  74 18 0
 2 1 606928 221332 20779576 4441668 0  0      125414 114102   2109 3646 2  6  74 18 0
 1 1 606928 225360 20776584 4440432 0  0      125389 126106   2122 3288 1  6  73 20 0
 1 1 606928 226712 20773400 4442740 0  0      125389 119439   2065 3291 1  6  74 18 0
 0 3 606928 247892 20748848 4446264 0  0      125133 103741   2014 3281 2  6  68 24 0
 0 2 606928 238596 20755732 4448696 0  0      115226 135512   2127 3230 2  6  71 20 0
 0 2 606928 234152 20757924 4448044 0  0      123445 131901   2216 4040 3  6  73 18 0
 1 2 606928 252320 20740332 4446900 0  0      123392 135939   2193 3433 1  7  73 19 0
 0 2 606928 245396 20747396 4446904 0  0      123443 128925   2259 5655 5  6  71 18 0
 1 3 606928 222832 20766180 4449504 0  0      123162 139278   2234 3591 1  7  74 18 0

편집 2

나는 변경을 시도했다 :

  • /proc/sys/vm/dirty_expire_centisecs
  • /proc/sys/vm/더티_배경_비율

이들 중 어느 것도 눈에 띄는 차이를 만들지 않았습니다. 그러나 /proc/sys/vm/dirty_Background_ratio를 10에서 1로 변경하면 ddrescue동작이 다음과 더 비슷해 집니다 cat.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 0  0 604700 306296 20348532 4373480    0    0 71526 102216 1545 2561  1  4 84 11  0
 0  1 604700 242724 20393720 4393508    0    0 123392 87694 1892 3152  2  6 80 13  0
 0  1 604700 230028 20402612 4393308    0    0 125389 124578 2139 3512  1  6 80 13  0
 1  0 604700 228944 20402148 4394620    0    0 125389 126991 2216 4064  2  6 78 14  0
 0  1 604696 253744 20341280 4431316    0    0 125415 128649 2683 6258  5  6 75 13  0
 1  1 604696 235080 20407744 4384972    0    0 125389 118890 2383 4816  4  6 76 14  0
 0  1 604696 285636 20346160 4398800    0    0 71475 109890 1809 10541  3  5 79 13  0
 2  2 604696 240168 20368092 4421908    0    0 114816 87582 1961 4467  3  5 79 12  0
 0  2 604696 240296 20377552 4411108    0    0 125389 121069 2251 4723  4  6 78 13  0
 1  1 604696 232420 20387084 4408712    0    0 125414 122238 2533 4376  2  6 78 13  0
 0  2 604696 238956 20387196 4402336    0    0 125389 123819 2659 5142  2  7 77 15  0
 2  0 604696 236288 20372312 4420324    0    0 124826 125246 2371 5450  4  6 74 16  0
 0  1 604696 293840 20335076 4399684    0    0 71450 107597 1882 5107  3  5 78 14  0
 1  1 604696 222776 20397184 4406132    0    0 108467 76212 2294 7814  4  5 80 12  0
 2  0 604696 230164 20397256 4398928    0    0 125372 121854 2527 4427  2  6 78 14  0
 0  1 604696 236932 20387916 4403792    0    0 125414 122394 2309 5088  3  6 78 13  0
 0  1 604696 242700 20388340 4396072    0    0 125414 128671 2355 5179  4  6 78 13  0
 0  1 604696 233416 20388316 4404064    0    0 125389 128662 2369 5511  5  6 76 14  0
 0  1 604696 237948 20402284 4384688    0    0 84250 104036 1919 5008  5  4 81  9  0
 1  2 604696 232280 20392248 4402312    0    0 125389 102426 2090 4531  3  5 78 14  0

여전히 30초마다(6행마다) 상당한 감소를 볼 수 있습니다.

관련 정보