dd đang tạo một tệp ngẫu nhiên 32 MB thay vì 1 GB

Tôi muốn tạo một tệp ngẫu nhiên 1 GB, vì vậy tôi đã sử dụng lệnh sau.

dd if=/dev/urandom of=output bs=1G count=1

Nhưng thay vào đó, mỗi lần tôi khởi chạy lệnh này, tôi nhận được một tệp 32 MB:

<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s

Chuyện gì thế?

BIÊN TẬP:

Nhờ những câu trả lời tuyệt vời trong chủ đề này, tôi đã đưa ra giải pháp đọc 32 khối lớn 32 MB, tạo ra 1GB:

dd if=/dev/urandom of=output bs=32M count=32

Một giải pháp khác được đưa ra là đọc 1 GB thẳng vào bộ nhớ và sau đó ghi vào đĩa. Giải pháp này chiếm rất nhiều bộ nhớ nên không bị ảnh hưởng:

dd if=/dev/urandom of=output bs=1G count=1 iflag=fullblock

bs, kích thước bộ đệm, nghĩa là kích thước của một lệnh gọi read () được thực hiện bởi dd.

(Ví dụ: cả hai bs=1M count=1và bs=1k count=1ksẽ dẫn đến tệp 1 MiB, nhưng phiên bản đầu tiên sẽ thực hiện trong một bước duy nhất, trong khi phiên bản thứ hai sẽ thực hiện trong 1024 khối nhỏ.)

Các tệp thông thường có thể được đọc ở gần như bất kỳ kích thước bộ đệm nào (miễn là bộ đệm đó phù hợp với RAM), nhưng các thiết bị và tệp "ảo" thường hoạt động rất gần với các cuộc gọi riêng lẻ và có một số hạn chế tùy ý về số lượng dữ liệu chúng sẽ tạo ra cho mỗi đọc () gọi.

Đối với /dev/urandom, giới hạn này được xác định trong urandom_read () trong trình điều khiển / char / Random.c :

#define ENTROPY_SHIFT 3

static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
    nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
    ...
}

Điều này có nghĩa là mỗi khi hàm được gọi, nó sẽ kẹp kích thước được yêu cầu thành 33554431 byte.

Theo mặc định, không giống như hầu hết các công cụ khác, dd sẽ không thử lại sau khi nhận được ít dữ liệu hơn yêu cầu - bạn nhận được 32 MiB và đó là nó. (Để làm cho nó thử lại tự động, như trong câu trả lời của Kamil, bạn sẽ cần chỉ định iflag=fullblock.)

Cũng lưu ý rằng "kích thước của một lần đọc ()" có nghĩa là toàn bộ bộ đệm phải vừa trong bộ nhớ cùng một lúc, vì vậy kích thước khối lớn cũng tương ứng với mức sử dụng bộ nhớ lớn của dd .

Và tất cả đều vô nghĩa vì bạn thường sẽ không đạt được bất kỳ hiệu suất nào khi vượt lên trên ~ 16 khối32 Khối MiB - tòa nhà không phải là phần chậm ở đây, trình tạo số ngẫu nhiên là.

Vì vậy, để đơn giản, chỉ cần sử dụng head -c 1G /dev/urandom > output.

ddcó thể đọc ít hơn ibs(lưu ý: bschỉ định cả hai ibsvà obs), trừ khi iflag=fullblockđược chỉ định. 0+1 records inchỉ ra rằng 0khối đầy đủ và khối 1một phần đã được đọc. Tuy nhiên, bất kỳ khối đầy đủ hoặc một phần làm tăng bộ đếm.

Tôi không biết cơ chế chính xác làm cho việc ddđọc một khối nhỏ hơn 1Gtrong trường hợp cụ thể này. Tôi đoán bất kỳ khối nào được đọc vào bộ nhớ trước khi nó được ghi, vì vậy việc quản lý bộ nhớ có thể gây trở ngại (nhưng đây chỉ là phỏng đoán). Chỉnh sửa: câu trả lời đồng thời này giải thích cơ chế giúp ddđọc một khối nhỏ hơn 1Gtrong trường hợp cụ thể này.

Dù sao, tôi không khuyên bạn nên lớn như vậy bs. Tôi sẽ sử dụng bs=1M count=1024. Điều quan trọng nhất là: không có iflag=fullblock bất kỳ nỗ lực đọc nào có thể đọc ít hơn ibs(trừ khi ibs=1, tôi nghĩ, điều này khá không hiệu quả).

Vì vậy, nếu bạn cần đọc một số lượng dữ liệu chính xác, sử dụng iflag=fullblock. Lưu ý iflaglà không bắt buộc bởi POSIX, bạn ddcó thể không hỗ trợ nó. Theo câu trả lời ibs=1 này có lẽ là cách POSIX duy nhất để đọc một số byte chính xác. Tất nhiên nếu bạn thay đổi ibsthì bạn sẽ cần phải tính toán lại count. Trong trường hợp của bạn giảm ibsxuống 32Mhoặc ít hơn có thể sẽ khắc phục vấn đề, ngay cả khi không có iflag=fullblock.

Trong Kubfox của tôi, tôi sẽ sửa lệnh của bạn như thế này:

dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock