Creazione di un file di grandi dimensioni in meno tempo


18

Voglio creare un file di grandi dimensioni ~ 10G pieno di zeri e valori casuali. Ho provato ad usare:

dd if=/dev/urandom of=10Gfile bs=5G count=10

Crea un file di circa 2 GB ed esce con uno stato di uscita '0'. Non riesco a capire perché?

Ho anche provato a creare file usando:

head -c 10G </dev/urandom >myfile

Ci vogliono circa 28-30 minuti per crearlo. Ma lo voglio creato più velocemente. Qualcuno ha una soluzione?

Inoltre desidero creare più file con lo stesso modello (pseudo) casuale per il confronto. Qualcuno sa un modo per farlo?


Benvenuto in AskUbuntu! Probabilmente stai ricevendo un errore a ddcausa della dimensione del blocco. Potresti voler dare un'occhiata a questo post stackoverflow.com/questions/6161823/… che ha alcune buone risposte su come calcolare la dimensione del blocco migliore, così come alcuni script / programmi utente e altri suggerimenti usando dd.
No Time

1
Dai un'occhiata anche a stackoverflow.com/questions/257844/…
muru,

Risposte:


12

Che ne dici di usare fallocate, questo strumento ci consente di preallocare lo spazio per un file (se il filesystem supporta questa funzione). Ad esempio, allocando 5 GB di dati in un file chiamato 'esempio', si può fare:

fallocate -l 5G example

Questo è molto più veloce di dd e assegnerà lo spazio molto rapidamente.


Questo file contiene dati casuali o contiene ciò che è accaduto nello spazio su disco allocato?
cprn,

Conterrà tutti gli zeri. Fondamentalmente, lo spazio è preallocato e, se non si modificano i dati, si presume che sia zero.
Colin Ian King,

Come può essere più veloce del dumping /dev/zeroallora?
cprn,

1
È molto veloce perché è una chiamata di sistema che blocca la preallocazione (ad esempio, riserva lo spazio ma esegue un minimo di I / O), in cui il passaggio da / dev / zero a un file comporta un carico di lettura / scrittura.
Colin Ian King,

Sto aumentando questo. Un'ultima domanda però ... Stavo usando truncatein passato e ho scoperto che non alloca fisicamente il file sul dispositivo e crea solo un file di grandi dimensioni arbitrario fino all'accesso, indipendentemente dallo spazio disponibile. Sei sicuro che non sia così fallocate? Lo controllerei ma sono su un cellulare ...
cprn il

9

È possibile utilizzare ddper creare un file costituito esclusivamente da zeri. Esempio:

dd if=/dev/zero of=zeros.img count=1 bs=1 seek=$((10 * 1024 * 1024 * 1024 - 1))

Questo è molto veloce perché solo un byte è realmente scritto sul disco fisico. Tuttavia, alcuni file system non lo supportano.

Se si desidera creare un file contenente contenuti pseudo-casuali, eseguire:

dd if=/dev/urandom of=random.img count=1024 bs=10M

Ti suggerisco di usare 10M come dimensione del buffer ( bs). Questo perché 10M non è troppo grande, ma offre comunque una buona dimensione del buffer. Dovrebbe essere piuttosto veloce, ma dipende sempre dalla velocità del tuo disco e dalla potenza di elaborazione.



1

Rispondere alla prima parte della tua domanda:

Cercare di scrivere un buffer di 5 GB alla volta non è una buona idea poiché il kernel probabilmente non lo supporta. Non ti darà alcun vantaggio in termini di prestazioni in ogni caso. Scrivere 1M alla volta è un buon massimo.


0

Questa domanda è stata aperta 5 anni fa. Mi sono appena imbattuto in questo e volevo aggiungere le mie scoperte.

Se lo usi semplicemente

dd if=/dev/urandom of=random.img count=1024 bs=10M

funzionerà in modo significativamente più veloce, come spiegato da xiaodongjie. Ma puoi renderlo ancora più veloce usando eatmydatalike

eatmydata dd if=/dev/urandom of=random.img count=1024 bs=10M

Ciò che eatmydatafa è disabilitare fsync rendendo la scrittura del disco più veloce.

Puoi leggere di più a riguardo su https://flamingspork.com/projects/libeatmydata/ .


1
Il modo in cui lo guardo ddè abbastanza veloce per cominciare, e si chiama libEAT-MY-DATA per un motivo.
Karel,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.