Có cách nào để xác định giá trị tối ưu cho tham số bs cho dd không?

Thỉnh thoảng tôi đã thấy các bình luận trực tuyến dọc theo dòng "đảm bảo bạn đặt 'bs =' vì giá trị mặc định sẽ mất quá nhiều thời gian" và những trải nghiệm cực kỳ không khoa học của riêng tôi, "dường như mất nhiều thời gian hơn thời gian tuần trước "dường như chịu được điều đó. Vì vậy, bất cứ khi nào tôi sử dụng 'dd' (thường trong phạm vi 1-2 GB), tôi đảm bảo chỉ định tham số byte. Khoảng một nửa thời gian tôi sử dụng giá trị được chỉ định trong bất kỳ hướng dẫn trực tuyến nào tôi đang sao chép từ; thời gian còn lại tôi sẽ chọn một số có ý nghĩa từ danh sách 'fdisk -l' cho những gì tôi giả sử là phương tiện chậm hơn (ví dụ: thẻ SD tôi đang viết).

Đối với một tình huống nhất định (loại phương tiện, kích thước xe buýt hoặc bất kỳ vấn đề nào khác), có cách nào để xác định giá trị "tốt nhất" không? Có dễ xác định không? Nếu không, có cách nào dễ dàng để đạt được 90-95% con đường đó không? Hay là "chỉ chọn một cái gì đó lớn hơn 512" thậm chí là câu trả lời đúng?

Tôi đã nghĩ đến việc tự mình thử nghiệm thử nghiệm, nhưng (ngoài việc có rất nhiều công việc) Tôi không chắc yếu tố nào ảnh hưởng đến câu trả lời, vì vậy tôi không biết cách thiết kế một thử nghiệm tốt.

ddngày trở lại khi cần dịch các băng máy tính cũ của IBM và kích thước khối phải khớp với băng được sử dụng để ghi băng hoặc các khối dữ liệu sẽ bị bỏ qua hoặc cắt bớt. . ổ đĩa có thể nhỏ hơn, nhưng 4KB là một trung gian hợp lý bất kể) và càng lớn thì càng tốt cho hiệu suất. Tôi thường sử dụng kích thước khối 1MB với ổ cứng. (Chúng tôi cũng có nhiều bộ nhớ hơn để ném xung quanh những ngày này.)

Có một cách để xác định kích thước khối tối ưu và đó là điểm chuẩn. Tôi vừa mới làm một điểm chuẩn nhanh chóng. Máy thử nghiệm là một PC chạy Debian GNU / Linux, với kernel 2.6.32 và coreutils 8.5. Cả hai hệ thống tập tin liên quan là ext3 trên khối lượng LVM trên một phân vùng đĩa cứng. Tệp nguồn là 2GB (chính xác là 2040000kB). Bộ nhớ đệm và bộ đệm được kích hoạt. Trước mỗi lần chạy, tôi làm trống bộ đệm sync; echo 1 >|/proc/sys/vm/drop_caches. Thời gian chạy không bao gồm một trận chung kết syncđể tuôn ra bộ đệm; trận chung kết syncdiễn ra theo thứ tự 1 giây. Các samelần chạy là các bản sao trên cùng một hệ thống tập tin; các difflần chạy là các bản sao đến một hệ thống tập tin trên một đĩa cứng khác. Để thống nhất, thời gian được báo cáo là thời gian đồng hồ treo tường thu được vớitimetiện ích, tính bằng giây. Tôi chỉ chạy mỗi lệnh một lần, vì vậy tôi không biết có bao nhiêu phương sai trong thời gian.

             same   diff
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Kết luận: kích thước khối lớn (vài megabyte) sẽ giúp, nhưng không đáng kể (ít hơn nhiều so với tôi dự kiến ​​cho các bản sao cùng ổ đĩa). Và catvà cpkhông thực hiện rất nặng nề. Với những con số này, tôi không thấy ddđáng bận tâm. Đi với cat!

Tôi đồng ý với geekizard rằng kích thước nên là bội số của kích thước khối, thường là 4K.

Nếu bạn muốn tìm kích thước khối stat -c "%o" filenamecó lẽ là lựa chọn dễ nhất.

Nhưng nói rằng bạn làm dd bs=4K, điều đó có nghĩa là nó read(4096); write(4096); read(4096); write(4096)...

Mỗi cuộc gọi hệ thống liên quan đến một bộ chuyển đổi ngữ cảnh, bao gồm một số chi phí, và tùy thuộc vào bộ lập lịch I / O, việc đọc với các lần ghi xen kẽ có thể khiến đĩa thực hiện nhiều lần tìm kiếm. (Có lẽ không phải là vấn đề lớn với bộ lập lịch Linux, nhưng dù sao cũng phải suy nghĩ.)

Vì vậy, nếu bạn làm như vậy bs=8K, bạn cho phép đĩa đọc hai khối cùng một lúc, có thể gần nhau trên đĩa, trước khi tìm một nơi khác để thực hiện ghi (hoặc dịch vụ I / O cho một quy trình khác).

Theo logic đó, bs=16Kthậm chí còn tốt hơn, vv

Vì vậy, những gì tôi muốn biết là nếu có giới hạn trên mà hiệu suất bắt đầu trở nên tồi tệ hơn, hoặc nếu nó chỉ bị giới hạn bởi bộ nhớ.

Như Gilles nói, bạn có thể xác định tham số tối ưu cho tùy chọn bs cho dd bằng cách đo điểm chuẩn. Điều này, mặc dù, đặt ra câu hỏi: làm thế nào bạn có thể thuận tiện điểm chuẩn tham số này?

Câu trả lời dự kiến ​​của tôi cho câu hỏi này là: sử dụng dd-opt , tiện ích gần đây tôi đã bắt đầu làm việc để giải quyết chính xác vấn đề này :)

Tôi đã tối ưu hóa cho đầu đọc sd2.0 usb2.0 dường như chạy tốt nhất bs=10M. Tôi đã thử 4k, lên tới 16M, sau 8-10M không cải thiện. Bạn có thể thấy cách đo tốc độ truyền giảm xuống ... rất có thể là do tải lên bộ đệm trên thiết bị sau đó chờ thiết bị chuyển sang phương tiện thực tế.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s