Tính toán dung lượng đĩa sẽ được sử dụng


25

Có trên Linux một chương trình có thể tính toán một chương trình sẽ tạo ra bao nhiêu dữ liệu không?

Ví dụ: nếu tôi muốn sao lưu cơ sở dữ liệu MySQL của mình, tôi thường làm

mysqldump > dumpfile.sql

Thay vào đó tôi muốn chuyển hướng đến /dev/nullnhưng tính toán dung lượng đĩa sẽ được sử dụng, như thế nào

mysqldump | fancy_space_calc_program

Đầu ra:

123456789 Bytes would have been used

Lưu ý, bản sao lưu MySQL chỉ là một ví dụ. Tôi biết rất rõ về cách tôi có thể ước tính kích thước trước đó, vì vậy xin vui lòng không có ý kiến ​​về điều đó.


1
Tôi thậm chí không nghĩ rằng bạn thực sự có thể làm cho một; đối với các trường hợp cụ thể có, nhưng không sử dụng chung, vì cách bạn có thể ước tính nếu một số ứng dụng gọi một số máy chủ và tải xuống dữ liệu từ đó - không có khả năng bạn có thể ước tính những điều đó trong các ứng dụng nước ngoài. Vì vậy, đây sẽ là mỗi ứng dụng - như bạn viết mà bạn đã biết về MYSQL - không có lời giải thích nào ở đó, nhưng các ứng dụng khác - trên mỗi ứng dụng, không có công cụ chung nào có thể thực hiện dự đoán chính xác như vậy.
Drako

1
Tôi hy vọng bạn nhận ra rằng bất kỳ nỗ lực nào để thực hiện ước tính sẽ yêu cầu thực sự chạy chương trình và quan sát đầu ra trong khi nó được gửi đi đâu đó an toàn. Điều này sẽ là không thể nếu chương trình có một số hiệu ứng không thể đảo ngược đối với một thứ khác để bạn CHỈ có thể chạy nó một lần mà không có tác dụng phụ ngoài ý muốn. Vấn đề khác là nếu chương trình lấy đầu ra của nó từ đầu vào thay đổi, lần chạy tiếp theo sẽ tạo ra một tệp đầu ra (kích thước khác) khác. Cuối cùng nhưng không kém phần quan trọng: không gian đĩa <> (byte đầu ra). Và các hệ thống tập tin khác nhau có chi phí khác nhau cho sổ sách kế toán.
Tonny

1
Vâng, tôi biết điều đó. Nó vẫn đủ tốt cho tôi.
FancyPants

@Drako Bạn có thể có một cách chung để đo đầu ra văn bản của một chương trình. Điều đó không cần phải có trên mỗi ứng dụng (xem ví dụ câu trả lời được chấp nhận). Việc đầu ra văn bản có giống nhau đáng tin cậy trong các lần chạy tiếp theo hay không là dành riêng cho ứng dụng, nhưng điều đó không ngăn bạn đo đầu ra một cách chung chung. Có lẽ OP và bất kỳ ai khác đang cố gắng đo lường đầu ra sẽ chỉ làm như vậy nếu dữ liệu có ý nghĩa đối với bất kỳ ứng dụng nào.
Jon Bentley

@JonBentley Tôi chưa bao giờ nói với bạn rằng bạn không thể có nó, hãy đọc kỹ hơn: "như tôi đã viết dự đoán chung sẽ không chính xác hoặc thậm chí đóng :)" và bây giờ hãy tưởng tượng rằng ứng dụng của tôi sau khi chạy sẽ kiểm tra các bản cập nhật của chính các plugin , v.v. và sẽ tải xuống x lượng dữ liệu từ i-net và lưu trữ dữ liệu đó trên hdd của bạn; Làm thế nào bạn sẽ đo chính xác trước với công cụ chung mà không biết gì về ứng dụng của tôi, sẽ cần bao nhiêu dung lượng sau khi chạy nó? Tuy nhiên, bạn vẫn có thể đoán đúng nhất với câu trả lời được chấp nhận và trong nhiều trường hợp thậm chí là khá chính xác.
Drako

Câu trả lời:


37

Lấy từ /programming/13418688/use-pipe-with-du-to-compute-size-of-stdin

Bạn có thể đặt nó để wc -cđếm số byte đi qua đường ống.

Tất nhiên, đây chỉ là các byte thô và không liên quan gì đến kích thước cung, v.v., vì vậy hãy lấy nó bằng một hạt muối ...


như tôi đã viết dự đoán chung sẽ không chính xác hoặc thậm chí đóng :)
Drako

6
@cat một triển khai tốt wcsẽ loại bỏ dữ liệu nó không còn cần thiết ngay khi thực tế.
Ruslan

2
@cat Tôi nghĩ rằng nó không có khả năng được đệm, vì bạn không cần đệm để đếm dòng hoặc ký tự. GNU coreutils wctrên máy tính của tôi dễ dàng xử lý dữ liệu stdin 40 GB, chỉ với bộ nhớ 8 GB.
Frxstrem

8
@Magnus. Tôi nghĩ rằng bạn đã bỏ lỡ trò chơi chữ. WC là một thuật ngữ tiếng Anh cho những gì người Mỹ gọi là phòng tắm. Bạn đang dẫn dữ liệu không sử dụng vào WC.
Vụ kiện của Quỹ Monica

3
@Frxstrem Bạn chắc chắn làm cần đệm để đếm dòng hoặc ký tự - ngay khi bạn đang không còn làm việc với một mã hóa đẳng cấu. Vì POSIX.2, wc -ckhông đếm ký tự - nó đếm byte. wc -mđếm nhân vật. Sự khác biệt rõ ràng nhất là ở các ký tự nhiều byte như trong UTF-16 hoặc Windows \r\n(hai byte trong ASCII, nhưng một ký tự). Không nhất thiết lúc nào cũng cần rất nhiều bộ đệm, nhưng Unicode có thể có một lượng byte tùy ý để thể hiện một ký tự; không phải thứ bạn thấy trong dữ liệu đáng tin cậy, mà là một vectơ tràn bộ đệm có thể.
Luaan

28

Lệnh pv là hoàn hảo cho việc này.

mysqldump | pv -b > /dev/null

Tôi nghĩ ở trên sẽ cung cấp cho bạn lệnh đúng mà bạn muốn, nó có thể cần một số điều chỉnh pv -b | > /dev/nullnhư tôi không thể kiểm tra ngay bây giờ

-b cung cấp cho bạn một giá trị tính bằng byte.


1
Thánh, tôi quên về pv cũng như wc. Xấu hổ với tôi Tôi muốn chấp nhận cả hai câu trả lời. Vì vậy, xin lỗi, nhưng Magnus đã nhanh hơn một chút và anh ta có thể sử dụng danh tiếng.
FancyPants

Vâng, đừng lo lắng, thủ thuật wc thực sự rất hay, không biết tại sao điều đó không xảy ra ngay lập tức với tôi. Lần đầu tiên tôi đi 'thanh!' sau đó nhận ra những gì tôi có nghĩa là pv! :)
djsmiley2k - CoW

Và bây giờ bạn đã khiến tôi băn khoăn về việc lấy tay cầm tập tin và kiểm tra kích thước trong / Proc ở đâu đó ....
djsmiley2k - CoW

2
Tôi chưa bao giờ nghe nói pvtrước đây .. Bạn học được điều gì đó mới mỗi ngày :)
Magnus

2
@Magnus: Tôi nghĩ wc cũ hơn (một phần của một số hệ thống Unix cũ hơn), không có nhiều tài liệu và pv (hoàn toàn có thể là kết quả) pv được cài đặt sẵn trong ít bản phân phối hơn. Tuy nhiên, tốt đẹp để biết về. Xem hình ảnh đẹp về mặt khái niệm này xuất phát từ trang chủ của chương trình "pv" ("người xem đường ống")
TUYỆT VỜI

0

Bạn có thể sử dụng ddcho nó, như thế này cat /dev/zero | dd status=progress of=/dev/null bs=4M.

Điều này cung cấp cho bạn một số dữ liệu trong và sau khi thực hiện về lượng dữ liệu được truyền cho nó, như:

$ cat /dev/zero | dd status=progress of=/dev/null                                                                                                                              
5371334656 bytes (5.4 GB, 5.0 GiB) copied, 4 s, 1.3 GB/s^C # this is progress data
12271136+0 records in #summary
12271135+0 records out #summary
6282821120 bytes (6.3 GB, 5.9 GiB) copied, 4.66683 s, 1.3 GB/s #summary
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.