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行ごとに)かなりの減少が見られます。

ベストアンサー1

おすすめ記事