Tworzenie pliku o dużym rozmiarze w krótszym czasie


18

Chcę utworzyć duży plik ~ 10G wypełniony zerami i losowymi wartościami. Próbowałem użyć:

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

Tworzy plik o wielkości około 2 Gb i wychodzi ze statusem wyjścia „0”. Nie rozumiem dlaczego?

Próbowałem także utworzyć plik, używając:

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

Utworzenie go zajmuje około 28-30 minut. Ale chcę, żeby powstało szybciej. Czy ktoś ma rozwiązanie?

Również chcę utworzyć wiele plików z tym samym (pseudo) losowym wzorem do porównania. Czy ktoś wie, jak to zrobić?


Witamy w AskUbuntu! Prawdopodobnie pojawia się błąd z ddpowodu rozmiaru bloku. Możesz przyjrzeć się temu postowi stackoverflow.com/questions/6161823/... zawiera on kilka dobrych odpowiedzi, jak obliczyć najlepszy rozmiar bloku, a także niektóre skrypty / programy użytkownika i inne sugestie dd.
— Nie ma czasu

Odpowiedzi:


12

Co powiesz na użycie fallocate, to narzędzie pozwala nam wstępnie przydzielić miejsce dla pliku (jeśli system plików obsługuje tę funkcję). Na przykład przydzielając 5 GB danych do pliku o nazwie „przykład”, można wykonać:

fallocate -l 5G example

Jest to znacznie szybsze niż dd i bardzo szybko przydziela miejsce.


Czy ten plik zawiera losowe dane, czy zawiera to, co się stało na przydzielonym miejscu na dysku?
— cprn

Będzie zawierać wszystkie zera. Zasadniczo przestrzeń jest wstępnie przydzielona, ​​a jeśli nie zmodyfikujesz danych, zakłada się, że wynosi zero.
— Colin Ian King,

Jak to może być szybsze niż zrzut /dev/zero?
— cprn

1
Jest bardzo szybki, ponieważ jest to jedno wywołanie systemowe, które blokuje wstępną alokację (np. Rezerwuje miejsce, ale robi minimalne operacje we / wy), gdzie jako dd'ing z / dev / zero do pliku wymaga obciążenia odczytu / zapisu.
— Colin Ian King,

Podnoszę ten. Ostatnie pytanie… Używałem truncatew przeszłości i dowiedziałem się, że nie przydziela fizycznie pliku na urządzeniu i po prostu tworzy dowolny duży plik do momentu uzyskania dostępu, niezależnie od dostępnej przestrzeni. Jesteś pewien, że tak nie jest fallocate? Sprawdziłbym to, ale jestem na telefonie komórkowym ...
— około

9

Możesz użyć dddo utworzenia pliku składającego się wyłącznie z zer. Przykład:

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

Jest to bardzo szybkie, ponieważ tylko jeden bajt jest naprawdę zapisywany na dysku fizycznym. Jednak niektóre systemy plików nie obsługują tego.

Jeśli chcesz utworzyć plik zawierający pseudolosową zawartość, uruchom:

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

Sugeruję użycie 10M jako rozmiaru bufora ( bs). Wynika to z faktu, że 10 M nie jest zbyt duże, ale nadal zapewnia dobry rozmiar bufora. Powinien być dość szybki, ale zawsze zależy od szybkości dysku i mocy przetwarzania.



1

Odpowiadając na pierwszą część pytania:

Próba zapisania bufora równego 5 GB nie jest dobrym pomysłem, ponieważ twoje jądro prawdopodobnie tego nie obsługuje. W żadnym wypadku nie przyniesie to żadnych korzyści. Pisanie 1M na raz to dobre maksimum.


0

To pytanie zostało otwarte 5 lat temu. Natknąłem się na to i chciałem dodać moje ustalenia.

Jeśli po prostu użyjesz

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

będzie działać znacznie szybciej, jak wyjaśnia Xiaodongjie. Ale możesz uczynić to jeszcze szybszym, używając eatmydatalike

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

Co eatmydatapowoduje, że wyłącza fsync, dzięki czemu dysk zapisuje się szybciej.

Możesz przeczytać więcej na ten temat na https://flamingspork.com/projects/libeatmydata/ .


1
Sposób, w jaki na to patrzę, ddjest wystarczająco szybki, i nazywa się to libEAT-MY-DATA z jakiegoś powodu.
— karel
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.