dd виробляє 32 Мб випадковий файл замість 1 ГБ

Я хотів створити 1 Гб випадковий файл, тому я використав наступну команду.

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

Але замість цього кожного разу, коли я запускаю цю команду, я отримую файл 32 Мб:

<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

Що не так?

Редагувати:

Завдяки чудовим відповідям у цій темі, я придумав рішення, яке читає 32 шматки величиною 32 Мб, що становить 1 Гб:

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

Було надано інше рішення, яке зчитує 1 Гб прямо в пам'ять, а потім записує на диск. Це рішення займає багато пам’яті, тому не бажане:

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

bs, розмір буфера, означає розмір одного виклику read (), здійсненого dd.

(Наприклад, і те, bs=1M count=1і bs=1k count=1kв результаті вийде файл 1 MiB, але перша версія зробить це в один крок, а друга - у 1024 невеликих шматках.)

Звичайні файли можна читати майже будь-якого розміру буфера (доки цей буфер вписується в оперативну пам’ять), але пристрої та "віртуальні" файли часто працюють дуже близько до окремих викликів і мають деяке довільне обмеження на кількість даних, які вони вироблять за читати () дзвінок.

Для /dev/urandomцього цей ліміт визначається в urandom_read () у драйверах / 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));
    ...
}

Це означає, що кожен раз, коли функція викликається, вона затискає потрібний розмір до 33554431 байт.

За замовчуванням, на відміну від більшості інших інструментів, dd не буде повторюватися після отримання меншої кількості даних, ніж вимагається - ви отримуєте 32 МіБ і все. (Щоб зробити це повторно автоматично, як у відповіді Каміля, вам потрібно буде вказати iflag=fullblock.)

Зауважимо також, що "розмір одного зчитування ()" означає, що весь буфер повинен вміщуватися в пам'яті відразу, тому масивні розміри блоків також відповідають масовому використанню пам'яті з боку dd .

І все безглуздо, тому що зазвичай ви не будете отримувати ніякої продуктивності при переході вище ~ 16–32 блоків MiB - систематичні дзвінки тут не є повільною частиною, генератор випадкових чисел.

Тому для простоти просто використовуйте head -c 1G /dev/urandom > output.

ddможе читати менше ibs(примітка: bsвказує і те, ibsі obs), якщо iflag=fullblockне вказано. 0+1 records inвказує, що 0повний блок та 1частковий блок були прочитані. Однак будь-який повний або частковий блок збільшує лічильник.

Я не знаю точного механізму, який змушує ddчитати блок, менший ніж 1Gу цьому конкретному випадку. Я думаю, що будь-який блок зчитується з пам'яті перед його написанням, тому управління пам’яттю може заважати (але це лише здогадка). Редагувати: ця відповідна відповідь пояснює механізм, який змушує ddчитати блок, менший, ніж 1Gу цьому конкретному випадку.

У всякому разі, я не рекомендую таких великих bs. Я б користувався bs=1M count=1024. Найголовніше: без iflag=fullblock будь-якої спроби читання може читати менше ibs(якщо ibs=1, на мою думку, це досить неефективно).

Тож якщо вам потрібно прочитати якусь точну кількість даних, використовуйте iflag=fullblock. Примітка iflagPOSIX не потрібна, ddможливо, вона не підтримує її. Відповідно до цієї відповіді ibs=1 , мабуть, єдиний спосіб POSIX зчитувати точну кількість байтів. Звичайно, якщо ви змінитесь, ibsвам потрібно буде перерахувати count. У вашому випадку зниження ibsдо 32Mменш ймовірно , вирішити проблему, навіть без iflag=fullblock.

У своєму Kubuntu я би виправив вашу команду так:

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