Làm thế nào tôi có thể làm cho dd chạy nhanh hơn?


0

Tôi có Samsung XE303C12 và tôi đã chạy Arch Linux ARM trên thẻ SD. Bảng phân vùng của thẻ SD là như vậy:

  1. Phân vùng nhân Chrome OS mà hạt nhân ALARM được bọc vboot chiếm.
  2. Phân vùng ext2 mà tôi sử dụng để định cấu hình U-Boot bất cứ khi nào nó được cài đặt vào phân vùng 1 thay vì kernel Arch Linux.
  3. Hệ thống tập tin gốc mà tôi đã cài đặt Arch Linux.

Một nỗ lực gần đây để cập nhật tất cả các gói cùng một lúc đã làm hỏng hệ thống tập tin gốc. Tôi thấy một số thông báo về việc flash kernel vào một số phân vùng trên thẻ SD và hệ thống tập tin không được gắn chỉ đọc hoặc đọc-ghi hoặc một cái gì đó. Tôi đã cố gắng sửa nó fsck, điều này đã nhắc tôi nhiều lần về việc phải làm gì với inodes, nhưng một khi tôi nhận ra rằng nó có thể sẽ hỏi tôi điều này cho mỗi inode trên phân vùng, tôi đã chạy fsck -y /dev/mmcblk1p3. Điều này chạy qua có thể vài trăm nút cho đến khi dừng lại. Tôi không thể nhớ thông báo lỗi.

Với hy vọng bảo toàn dữ liệu để phục hồi trong tương lai, tôi đang sao lưu /dev/mmcblk1p3hệ thống tập tin FAT32 trên ổ USB bằng cách sử dụng dd. Vì FAT32 không thể chứa các tệp lớn hơn 4 GiB, tôi đã quyết định chia nó thành các phân đoạn bằng cách sử dụng một số mã shell và vòng lặp.

Bỏ qua một vài điều, tôi đã nhận ra rằng ddnhanh hơn khi bắt đầu quá trình (tôi đã sử dụng bscài đặt thành bội số lớn hơn 512 để làm cho nó nhanh hơn), vì vậy phân đoạn 64 MiB đầu tiên sẽ được ghi vào hệ thống tệp USB trong 3 giây và nó sẽ dần dần chậm hơn với mỗi lần lặp. Tôi phát hiện ra rằng điều này là do bộ đệm đĩa đầy.

Tôi tìm kiếm một cách để xóa bộ nhớ cache ddvà tôi tình cờ thấy bài đăng này trên trang web Unix Stack Exchange. Câu trả lời hàng đầu nói phải làm sync; echo 3 > /proc/sys/vm/drop_caches. Một nhận xét về câu trả lời đó lưu ý rằng cài đặt đó không bị dính và liên kết trong nhận xét đó đã cho tôi ý tưởng để thực hiện echo 3 > /proc/sys/vm/drop_cachestrước mỗi lần lặp lại dd. Tôi đã thử điều đó và ddvẫn giảm tốc độ sao chép.

Giải pháp thứ hai đề cập trong câu trả lời các bài viết đầu tiên là để chạy ddvới iflag=directnhư là một cách để bỏ qua bộ nhớ cache. Tôi đã làm điều đó nhưng tôi cũng đã sử dụng oflag=directvì tôi nghĩ rằng bộ đệm sẽ áp dụng cho cả việc sao chép từ thẻ SD và ghi vào USB. Nhận xét này nói rằng nocachenên được sử dụng thay vì direct, vì vậy tôi cũng đã thử nó. Cả hai phương pháp đều có cùng mức giảm từ ~ 17 MB / s xuống ~ 1-3 MB / s.

Tôi đoán rằng tôi có thể không sử dụng các phương thức đó một cách chính xác, vì vậy có cách nào đáng tin cậy để xóa bộ đệm mỗi lần lặp lại để thực hiện ddnhanh hơn hoặc một số cách để hoàn toàn không sử dụng bộ đệm?


Bạn đang sử dụng khối gì (bs =) với dd? Q đề cập đến 512 byte và "bội số" ... Và bạn đang sao chép cài đặt Arch trên thẻ sd, vào ổ cứng tôi đoán vậy?
Xen2050

@ Xen2050 Tôi đã thử sử dụng kích thước khối là các 2^xbyte xcó số nguyên từ 12 đến 25. Tôi đang sao chép phân vùng thẻ SD vào ổ USB.
Melab

1
Đối với hầu hết các phần, bạn sẽ thấy rằng dd đang bắt đầu nhanh hơn bởi vì nó có thể lưu trữ các lần đọc, nhưng cuối cùng nó cần phải bắt đầu ghi chúng vào đĩa. Nén đầu ra nhanh chóng trước khi viết sẽ giúp bạn tiết kiệm thời gian nếu đó là một tùy chọn - nhưng điều quan trọng (sau khi bạn đã tăng kích thước khối, như bạn đã xử lý xong) là để có được thẻ sd nhanh hơn!
davidgo

Câu trả lời:


0

Miễn là kích thước khối ( bs) được sử dụng ddđủ lớn, nó thực sự chỉ bị giới hạn bởi tốc độ phần cứng. Tôi nghi ngờ bạn sẽ phải chờ đợi.

Bây giờ tôi cần một máy tính ... không thể tìm thấy, chỉ bc. Vì vậy, bạn đang sử dụng bs=từ 2 đến sức mạnh của 25 ... khoảng 33 triệu, đủ lớn (fyi, sử dụng một số nhỏ bsnhư 1 hoặc 512 thường sẽ làm chậm dd khi bò).

Thậm chí có khả năng, thẻ sd & / hoặc ổ đĩa USB sẽ không đọc và ghi nhanh hơn nữa. Việc ghi "nhanh" ban đầu có lẽ chỉ là lấp đầy bộ đệm ghi và ghi thực sự luôn có cùng tốc độ chậm. Xóa bộ nhớ cache trước tiên sẽ chỉ tạo ảo giác về việc ghi nhanh hơn trong một thời gian dài hơn.

Vì vậy, Arch đã cài đặt trên thẻ SD của bạn bị hỏng hoàn toàn và hệ thống tệp bị hỏng nghiêm trọng và bạn đã chạy fsck một vài lần trên nó ... Tôi đoán rằng việc sửa chữa cài đặt gần như vô vọng và cài đặt mới sẽ là 1000 lần nhanh hơn & dễ dàng hơn.

Nếu bạn có thể gắn kết nó & sao chép bất kỳ dữ liệu nào đáng lưu giữ, tại sao không làm điều đó ngay bây giờ và quên đi việc khôi phục thêm? Dữ liệu quan trọng luôn phải có một bản sao lưu , vì vậy thực sự không nên làm gì nhiều.

FYI, Bạn cũng có thể nén ddhình ảnh trước khi viết nó, gz ống độc đáo và sẽ tiết kiệm rất nhiều không gian nếu có nhiều số không trong không gian trống, nhưng điều đó khiến việc gắn hình ảnh trở nên khó khăn hơn. Squashfs cũng có thể hình ảnh toàn bộ ổ đĩa, để truy cập chỉ đọc có thể gắn kết sau này.

[Cũng có thể đặt điều này trong một "câu trả 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.