Nén luồng nhanh mà không tràn vào tài nguyên phần cứng?

Tôi có dung lượng ổ đĩa trống 200 GB, RAM 16 GB (trong đó ~ 1 GB bị chiếm bởi máy tính để bàn và kernel) và 6 GB trao đổi.

Tôi có ổ SSD ngoài 240 GB, với 70 GB được sử dụng ¹ và phần còn lại miễn phí, tôi cần sao lưu vào đĩa của mình.

Thông thường, tôi sẽ dd if=/dev/sdb of=Desktop/disk.imgđĩa trước, sau đó nén nó, nhưng làm cho hình ảnh trước không phải là một tùy chọn vì làm như vậy sẽ cần nhiều không gian đĩa hơn tôi có, mặc dù bước nén sẽ dẫn đến không gian trống bị nén nên lưu trữ cuối cùng có thể dễ dàng phù hợp trên đĩa của tôi.

ddghi vào STDOUT theo mặc định và gzipcó thể đọc từ STDIN, vì vậy theo lý thuyết tôi có thể viết dd if=/dev/sdb | gzip -9 -, nhưng gzipmất nhiều thời gian hơn để đọc byte hơn là ddcó thể tạo ra chúng.

Từ man pipe:

Dữ liệu được ghi vào đầu ghi của ống được đệm bởi nhân cho đến khi nó được đọc từ đầu đọc của ống.

Tôi hình dung |giống như một đường ống thực sự - một ứng dụng đẩy dữ liệu vào và ứng dụng khác lấy dữ liệu ra khỏi hàng đợi của đường ống càng nhanh càng tốt.

Điều gì khi chương trình ở phía bên trái ghi nhiều dữ liệu nhanh hơn phía bên kia của đường ống có thể hy vọng xử lý nó? Nó sẽ gây ra bộ nhớ cực lớn hoặc sử dụng trao đổi, hoặc hạt nhân sẽ cố gắng tạo ra một bộ xếp hình trên đĩa, do đó làm đầy đĩa? Hoặc nó sẽ thất bại SIGPIPE Broken pipenếu bộ đệm quá lớn?

Về cơ bản, điều này rút ra hai câu hỏi:

1. Ý nghĩa và kết quả của việc đẩy nhiều dữ liệu vào một đường ống hơn là được đọc tại một thời điểm?
2. Cách đáng tin cậy để nén một luồng dữ liệu vào đĩa mà không đưa toàn bộ luồng dữ liệu không nén vào đĩa?

_{Lưu ý 1: Tôi không thể chỉ sao chép chính xác 70 GB đầu tiên được sử dụng và mong muốn có được một hệ thống làm việc hoặc hệ thống tập tin, vì sự phân mảnh và những thứ khác sẽ yêu cầu toàn bộ nội dung.}

Về mặt kỹ thuật, bạn thậm chí không cần dd:

gzip < /dev/drive > drive.img.gz

Nếu bạn làm sử dụng dd, bạn nên luôn luôn đi với lớn hơn kích cỡ khối mặc định như dd bs=1Mhoặc bị quái syscall ( dd's kích cỡ khối mặc định là 512 byte, vì nó read()s và write()s đó là 4096syscalls mỗi MiB, quá nhiều chi phí).

gzip -9sử dụng rất nhiều CPU với rất ít để hiển thị cho nó. Nếu gziplàm bạn chậm lại, hãy giảm mức độ nén hoặc sử dụng phương pháp nén khác (nhanh hơn).

Nếu bạn đang thực hiện sao lưu dựa trên tệp thay vì ddhình ảnh, bạn có thể có một số logic quyết định có nén hay không (không có cách nào để làm như vậy đối với các loại tệp khác nhau). dar( tarthay thế`) là một ví dụ có các tùy chọn để làm như vậy.

Nếu không gian trống của bạn là ZERO (vì đó là ổ SSD trả về 0 một cách đáng tin cậy sau TRIM và bạn đã chạy fstrimvà bỏ bộ nhớ cache), bạn cũng có thể sử dụng ddvới conv=sparsecờ để tạo một hình ảnh thưa thớt, không thể nén, có thể lặp, sử dụng không gian đĩa cho vùng 0 . Yêu cầu tệp hình ảnh phải được hỗ trợ bởi một hệ thống tệp hỗ trợ các tệp thưa thớt.

Ngoài ra, đối với một số hệ thống tập tin, có các chương trình chỉ có thể hình ảnh các khu vực được sử dụng.

ddđọc và ghi dữ liệu một khối tại một thời điểm và nó chỉ có một khối xuất sắc. Vì thế

valgrind dd if=/dev/zero status=progress of=/dev/null bs=1M

cho thấy ddsử dụng khoảng 1 MB bộ nhớ. Bạn có thể chơi xung quanh với kích thước khối và thả valgrind, để xem hiệu ứng về ddtốc độ.

Khi bạn đi vào gzip, ddchỉ cần chậm lại để phù hợp với gziptốc độ của. Việc sử dụng bộ nhớ của nó không tăng, cũng không khiến kernel lưu trữ bộ đệm trên đĩa (kernel không biết cách thực hiện điều đó, ngoại trừ thông qua trao đổi). Một đường ống bị vỡ chỉ xảy ra khi một trong hai đầu của ống chết; xem signal(7)và write(2)để biết chi tiết.

Như vậy

dd if=... iconv=fullblock bs=1M | gzip -9 > ...

là một cách an toàn để làm những gì bạn đang theo đuổi.

Khi đường ống, quá trình viết kết thúc bị chặn bởi kernel nếu quá trình đọc không theo kịp. Bạn có thể thấy điều này bằng cách chạy

strace dd if=/dev/zero bs=1M | (sleep 60; cat > /dev/null)

Bạn sẽ thấy rằng ddđọc 1MB, sau đó phát hành một write()cái ngồi đó chờ trong một phút trong khi sleepchạy. Đó là cách cả hai mặt của một đường ống cân bằng: các khối nhân ghi nếu quá trình viết quá nhanh và nó chặn đọc nếu quá trình đọc quá nhanh.

Không có ý nghĩa tiêu cực nào khác ngoài hiệu suất: đường ống có bộ đệm, thường là 64K và sau đó, ghi vào đường ống sẽ đơn giản chặn cho đến khi gzipđọc thêm một số dữ liệu.

Trả lời câu hỏi thực tế về cách thức hoạt động của nó: "điều gì xảy ra nếu chương trình ở phía bên trái ghi nhiều dữ liệu nhanh hơn phía bên kia của đường ống có thể hy vọng xử lý nó?"

Điều này không xảy ra. Có một bộ đệm khá nhỏ, kích thước hạn chế trong đường ống; xem bộ đệm ống lớn như thế nào?

Khi bộ đệm ống đầy, chương trình gửi sẽ chặn . Khi nó thực hiện một cuộc gọi ghi, kernel sẽ không trả lại quyền điều khiển cho chương trình cho đến khi dữ liệu được ghi vào bộ đệm. Điều này cho thời gian CPU chương trình đọc để làm trống bộ đệm.

Có lẽ bạn chỉ cần các tập tin, sau đó sử dụng tar. Bạn có thể điền vào các số không các khối không chứa bất cứ thứ gì bạn muốn, ai đó đã hỏi về nó. Xóa không gian không sử dụng với số không (ext3, ext4)

Sau đó, pigzthường có nhanh hơn gzip.