Có phương pháp nào để có được tỷ lệ phần trăm trên DD trong linux không?


43

Vì vậy, đây là những gì đang xảy ra.

Tôi đã bắt đầu sao lưu ổ đĩa trên máy chủ của mình thông qua USB trực tiếp Linux. Tôi bắt đầu sao chép ổ đĩa đầu tiên bằng ddlệnh vanilla; chỉ sudo dd if=/dev/sda of=/dev/sdc1và sau đó tôi nhớ rằng điều này chỉ để trống giao diện điều khiển cho đến khi nó kết thúc.

Dù sao tôi cũng cần chạy một bản sao lưu khác nhau cho cùng một ổ đĩa, vì vậy tôi cũng bắt đầu một bản sao lưu sudo dd if=/dev/sdb of=/dev/sdc3 status=progressđó và sau đó tôi nhận được một dòng văn bản cho thấy tốc độ truyền hiện tại cũng như tiến trình tính bằng byte.

Tôi đã hy vọng một phương pháp cho thấy tỷ lệ phần trăm của bản sao lưu thay vì thực hiện phép toán có bao nhiêu byte được sao lưu trong số 1,8TB. Có cách nào dễ dàng hơn để làm điều này hơn trạng thái = tiến độ không?

Câu trả lời:


69

Xem câu trả lời từ câu hỏi này [ 1 ]

pv

Ví dụ bạn có thể sử dụng pv trước khi bắt đầu

sudo apt-get install pv    # if you do not have it
pv < /dev/sda > /dev/sc3   # it is reported to be faster
pv /dev/sda > /dev/sc3     # it seems to have the same speed of the previous one
#or 
sudo dd if=/dev/sda | pv -s 1844G | dd of=/dev/sdc3  # Maybe slower 

Đầu ra [ 2 ] :

440MB 0:00:38 [11.6MB/s] [======>                             ] 21% ETA 0:02:19

Lưu ý:
Đặc biệt đối với các tệp lớn bạn có thể muốn xem man ddvà đặt các tùy chọn cần thiết để tăng tốc tất cả trên phần cứng của mình, ví dụ: bs=100Mđể đặt bộ đệm, oflag=syncđể đếm các byte hiệu quả được ghi, có thể direct...
Tùy chọn này -schỉ lấy tham số nguyên 1.8T-->1844G.
Như bạn có thể nhận thấy từ những dòng đầu tiên bạn không cần dd.


kill -USR1 pid

Nếu bạn đã đưa ra các ddlệnh, một khi bạn đã được định rõ PID của nó ( Ctrl- Z+ bgvà bạn đọc nó, hoặc pgrep ^dd...), bạn có thể gửi một tín hiệu USR1(hoặc SIGUSR1, hoặc SIGINFOxem dưới đây) và đọc kết quả.
Nếu PID của chương trình là 1234 với

kill -USR1 1234

dd sẽ trả lời trên thiết bị đầu cuối STDERR của nó với một cái gì đó tương tự như

4+1 records in
4+0 records out
41943040 bytes (42 MB) copied, 2.90588 s, 14.4 MB/s

Cảnh báo: Trong OpenBSD, bạn có thể phải kiểm tra trước hành vi của kill[ 3 ] : sử dụng thay thế
kill -SIGINFO 1234.
Nó tồn tại các sigaction được đặt tên SIGINFO. Các SIGUSR1một, trong trường hợp này, nên chấm dứt chương trình ( dd) ...
Dưới Ubuntu sử dụng -SIGUSR1( 10).


9
bạn gần như chắc chắn sẽ thấy rằng việc sử dụng 'bs' trên lệnh dd cực kỳ tăng tốc. Giống như dd if = / dev / blah of = / tmp / blah bs = 100M để chuyển các khối 100M cùng một lúc
Sirex

1
@Sirex Tất nhiên bạn phải đặt bs để tối ưu hóa tốc độ truyền liên quan đến phần cứng của bạn ... Trong câu trả lời chỉ là lặp lại dòng lệnh của OP. :-)
Hastur

3
@Criggie: điều đó có thể là do ddđã hoàn thành tất cả các write()cuộc gọi hệ thống và fsynchoặc closebị chặn chờ ghi vào đĩa. Với thẻ nhớ USB chậm, ngưỡng bộ đệm I / O Linux mặc định cho mức độ bộ đệm ghi bẩn lớn có thể dẫn đến hành vi khác biệt về chất lượng so với các tệp lớn trên đĩa nhanh, bởi vì bộ đệm lớn như những gì bạn đang sao chép và nó vẫn mất thời gian đáng chú ý.
Peter Cordes

5
Câu trả lời chính xác. Tuy nhiên, tôi muốn lưu ý rằng trong OpenBSD, tín hiệu tiêu diệt đúng là SIGINFO, không phải SIGUSR1. Sử dụng -USR1 trong OpenBSD sẽ giết chết dd. Vì vậy, trước khi bạn thử điều này trong một môi trường mới, trên một giao dịch mà bạn không muốn làm gián đoạn, bạn có thể muốn làm quen với cách môi trường hoạt động (trong bài kiểm tra an toàn hơn).
TUYỆT VỜI 2/2/18

1
những lời khuyên tín hiệu cho ddlà thông tin thực sự tuyệt vời, đặc biệt là cho các máy chủ, nơi bạn có thể không / không muốn cài đặtpv
mike

38

Công cụ truy cập của tôi cho loại công cụ này là progress:

Công cụ này có thể được mô tả như một lệnh Tiny , Dirty, Linux và OSX-Only C tìm kiếm các lệnh cơ bản của coreutils (cp, mv, dd, tar, gzip / gunzip, cat, v.v.) hiện đang chạy trên hệ thống của bạn và hiển thị phần trăm dữ liệu được sao chép. Nó cũng có thể hiển thị thời gianthông lượng ước tính và cung cấp chế độ "giống như trên" (giám sát).

Ảnh chụp màn hình "<code> tiến trình </ code>"

Nó chỉ đơn giản là quét /proccác lệnh thú vị, sau đó xem các thư mục fdfdinfotìm các tệp đã mở và tìm kiếm các vị trí cũng như báo cáo trạng thái cho tệp lớn nhất.

Nó rất nhẹ và tương thích với hầu hết mọi lệnh.

Tôi thấy nó đặc biệt hữu ích vì:

  • so với pvtrong ống hoặc dcfldd, tôi không phải nhớ chạy một lệnh khác khi tôi bắt đầu hoạt động, tôi có thể theo dõi công cụ sau khi thực tế;
  • so với kill -USR1, nó hoạt động trên hầu hết mọi lệnh, tôi không phải luôn kiểm tra kỹ trang chủ để đảm bảo rằng tôi không vô tình giết chết bản sao; Ngoài ra, thật tuyệt khi, khi được gọi mà không có tham số, nó sẽ hiển thị tiến trình cho bất kỳ lệnh "truyền dữ liệu" phổ biến nào hiện đang chạy, vì vậy tôi thậm chí không phải tìm kiếm PID;
  • so với pv -d, một lần nữa tôi không cần phải tìm kiếm PID.

1
Lưu ý: Bạn có thể giám sát nhiều hơn các quy trình coreutils. Đơn giản chỉ cần xác định tên của lệnh với --command <command-name>.
jpaugh

1
Điều này thật tuyệt!
Floris

25

Chạy dd, sau đó, trong một shell riêng, gọi lệnh sau:

pv -d $(pidof dd) # root may be required

Điều này sẽ làm cho pv có được số liệu thống kê về tất cả các mô tả tệp đã mở của ddquá trình. Nó sẽ cho bạn thấy cả bộ đệm đọc và ghi.


2
Hoạt động sau khi thực tế!? Kinh ngạc!!
jpaugh

3
Điều đó thật ngầu. Nó tránh được băng thông bộ nhớ + phí chuyển đổi ngữ cảnh của việc thực sự dẫn tất cả dữ liệu qua 3 quy trình! @jpaugh: Tôi đoán nó chỉ nhìn vào /proc/$PID/fdinfocác vị trí tập tin, và tại /proc/$PID/fdđể xem file (và do đó các kích thước). Vì vậy, vâng, rất hay và ý tưởng hay cho một tính năng, nhưng tôi sẽ không gọi nó là "tuyệt vời" bởi vì có các API Linux cho phép nó thăm dò vị trí tệp của một quy trình khác.
Peter Cordes

@PeterCordes Tôi không nhận ra vị trí tệp bị lộ bởi kernel. (Tôi đã dành cả đời để chuẩn bị kỹ lưỡng các pvđường ống trước.) Tất nhiên, tôi đã giả sử nhiều như vậy khi tôi thấy rằng việc này không hiệu quả.
jpaugh

9

Có một sự thay thế cho dd: dcfldd.

dcfldd là phiên bản nâng cao của GNU GNU với các tính năng hữu ích cho pháp y và bảo mật.

Đầu ra trạng thái - dcfldd có thể cập nhật cho người dùng về tiến trình của nó về lượng dữ liệu được truyền và thời gian hoạt động sẽ kéo dài bao lâu.

dcfldd if=/dev/zero of=out bs=2G count=1 # test file
dcfldd if=out of=out2 sizeprobe=if
[80% of 2047Mb] 52736 blocks (1648Mb) written. 00:00:01 remaining.

http://dcfldd.sourceforge.net/
https://linux.die.net/man/1/dcfldd


Đó là một tên lệnh dài hơn ... rõ ràng, nó kém hơn. (+1)
jpaugh

7

Theo tỷ lệ phần trăm bạn phải thực hiện một số phép toán, nhưng bạn có thể nhận được tiến trình của một dd ở dạng người có thể đọc được, ngay cả sau khi đã bắt đầu, bằng cách thực hiện kill -USR1 $(pidof dd)

Quá trình dd hiện tại sẽ hiển thị tương tự như:

11117279 byte (11 MB, 11 MiB) được sao chép, 13.715 giây, 811 kB / s


4
Về cơ bản, đó là điều tương tự status=progressmang lại
rakslice

1
Tôi thực sự đã định nói rằng đó chính xác là điều tương tự mà status = tiến trình mang lại.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.