dd sta producendo un file casuale da 32 MB anziché 1 GB

Volevo produrre un file casuale da 1 GB, quindi ho usato il seguente comando.

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

Ma invece ogni volta che lancio questo comando ottengo un file da 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

Che c'è?

MODIFICARE:

Grazie alle ottime risposte in questo argomento, sono arrivato con una soluzione che legge 32 blocchi di 32 MB di larghezza che rende 1 GB:

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

È stata fornita un'altra soluzione che legge 1 GB direttamente nella memoria e quindi scrive sul disco. Questa soluzione richiede molta memoria, quindi non è preffered:

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

bs, la dimensione del buffer, indica la dimensione di una singola chiamata read () eseguita da dd.

(Ad esempio, entrambi bs=1M count=1e bs=1k count=1ksi tradurrà in un file 1 MiB, ma la prima versione lo farà in un solo passaggio, mentre la seconda lo farà in 1024 piccoli blocchi.)

I file regolari possono essere letti a quasi tutte le dimensioni del buffer (purché il buffer si adatti alla RAM), ma i dispositivi e i file "virtuali" spesso lavorano molto vicino alle singole chiamate e hanno una restrizione arbitraria di quanti dati produrranno per read () call.

Per /dev/urandom, questo limite è definito in urandom_read () in drivers / 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));
    ...
}

Ciò significa che ogni volta che viene chiamata la funzione, bloccherà la dimensione richiesta a 33554431 byte.

Per impostazione predefinita, a differenza della maggior parte degli altri strumenti, dd non riproverà dopo aver ricevuto meno dati di quelli richiesti: ottieni 32 MiB e basta. (Per riprovare automaticamente, come nella risposta di Kamil, dovrai specificare iflag=fullblock.)

Si noti inoltre che "la dimensione di un singolo read ()" significa che l'intero buffer deve adattarsi alla memoria in una sola volta, quindi le dimensioni massime dei blocchi corrispondono anche all'utilizzo massiccio della memoria da parte di dd .

Ed è tutto inutile perché di solito non otterrai alcuna prestazione quando vai sopra ~ 16–32 blocchi MiB - le syscalls non sono la parte lenta qui, il generatore di numeri casuali lo è.

Quindi, per semplicità, basta usare head -c 1G /dev/urandom > output.

ddpuò leggere meno di ibs(nota: bsspecifica entrambi ibse obs), a meno che non iflag=fullblocksia specificato. 0+1 records inindica che 0sono 1stati letti blocchi completi e blocchi parziali. Tuttavia, qualsiasi blocco completo o parziale aumenta il contatore.

Non conosco il meccanismo esatto che fa ddleggere un blocco che è inferiore rispetto 1Ga questo caso particolare. Immagino che qualsiasi blocco venga letto nella memoria prima che sia scritto, quindi la gestione della memoria potrebbe interferire (ma questa è solo una supposizione). Modifica: questa risposta simultanea spiega il meccanismo che rende la ddlettura di un blocco inferiore rispetto 1Ga questo caso particolare.

Comunque, non lo consiglio così grande bs. Vorrei usare bs=1M count=1024. La cosa più importante è: senza iflag=fullblock alcun tentativo di lettura può leggere meno di ibs(a meno che ibs=1, a mio avviso, non sia abbastanza inefficiente).

Quindi, se hai bisogno di leggere una quantità esatta di dati, usa iflag=fullblock. Nota iflagnon è richiesta da POSIX, il tuo ddpotrebbe non supportarlo. Secondo questa risposta ibs=1 è probabilmente l'unico modo POSIX per leggere un numero esatto di byte. Naturalmente, se cambi ibs, dovrai ricalcolare il file count. Nel tuo caso l'abbassamento ibsa 32Mo meno probabilmente risolvere il problema, anche senza iflag=fullblock.

Nel mio Kubuntu avrei corretto il tuo comando in questo modo:

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