ランダムバイトの大きなファイルをすばやく作成する
ゼロとランダムな値で満たされた10G以下の大きなファイルを作成したいと思います。私は使ってみました：
dd if=/dev/urandom of=10Gfile bs=5G count=10
約2Gbのファイルを作成し、終了ステータス0で終了します。理由がわかりません。
私も使用してファイルを作成してみました：
head -c 10G </dev/urandom >myfile
作成には約28〜30分かかります。しかし、私はそれをより速く作成したいです。誰かが解決策を持っていますか？
また、比較のために同じ（疑似）ランダムパターンで複数のファイルを作成したいと思います。誰かがそれを行う方法を知っていますか？ありがとう
私は commandlinef でかなり巧妙なトリックを見てきました：ランダム性のソースとして/dev/urandomを使用してください（それはis良いソースです） 、それをAESストリーム暗号のパスワードとして使用します。
100％確実とは言えませんが、パラメーターを変更する場合（つまり、wayを使用すると、/dev/urandomから128バイト以上を超えると思います）、それはすべての実用的な目的のために、暗号的に安全なPRNGに少なくとも十分近いです：
このコマンドは、/ dev/urandomによってシードが設定されたaes-256-ctrを使用して、疑似ランダムデータストリームを生成します。安全なデータスクランブリングのためにブロックデバイスにリダイレクトします。
openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > randomfile.bin
これはどのように作動しますか？
openssl enc -aes-256-ctrはopensslを使用して、CTRモードのAES-256でゼロを暗号化します。
何を暗号化しますか？
/dev/zero暗号化に使用するパスワードは何ですか？
dd if=/dev/urandom bs=128 count=1 | base64これは、base64でエンコードされた128バイトの
/dev/urandomの1ブロックです（/dev/nullへのリダイレクトはエラーを無視することです）。OpenSSLのマニュアルページには次のように記載されているため、実際に
-nosaltが使用されている理由はわかりません。-salt use a salt in the key derivation routines. This is the default. -nosalt don't use a salt in the key derivation routines. This option SHOULD NOT be used except for test purposes or compatibility with ancient versions of OpenSSL and SSLeay.おそらくポイントは、これを可能な限り高速にすることであり、ソルトの使用は正当化されませんが、これが暗号文に何らかのパターンを残すかどうかはわかりません。 Cryptography Stack Exchangeの人々は、それについてより完全な説明をすることができるかもしれません。
入力は
/dev/zeroです。これは、何が暗号化されているかは本当に重要ではないためです-出力はランダムなデータに似たものになります。ゼロは取得が高速であり、ゼロを使い果たすことなく、必要なだけ取得（および暗号化）できます。出力は
randomfile.binです。/dev/sdzにすることもでき、ブロックデバイス全体をランダム化します。
でも、固定サイズのファイルを作りたい！それ、どうやったら出来るの？
シンプル！
dd if=<(openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero) of=filename bs=1M count=100 iflag=fullblock
固定のdd（ここでは1 MB）とblocksizeを付けたコマンドをcountします。ファイルサイズはblocksize * count = 1M * 100 = 100Mです。
shredユーティリティを使用すると、速度が向上します。
- 2Gと
dd in=/dev/urandom-250秒 - 2Gと
openssl Rand-81秒 - 2G、
shred-39秒
したがって、shredを使用した10Gの場合、約3〜4分かかります。
空のファイルを作成し、必要なファイルサイズを渡して細断処理します。
touch file
shred -n 1 -s 10G file
生成されたデータを暗号で安全に保護する方法はわかりませんが、ランダムに見えます。 ここ についての情報です。
乱数ジェネレータプログラム sharand があり、ランダムバイトをファイルに書き込みます。 （プログラムは最初は1文字少ないsharndと呼ばれていました（ http://mattmahoney.net/dc/ を参照）
/dev/urandomを読むのに比べて約3分の1の時間がかかります
これは安全なRNGです。高速ではありますが、安全ではありませんが、それは通常必要なことではありません。
本当に高速にするには、PerlのRNGアルゴリズムのコレクションを探します：libstring-random-Perl。
試してみましょう（apt-get install sharand）：
$ time sharand a 1000000000
sharand a 1000000000 21.72s user 0.34s system 99% cpu 22.087 total
$ time head -c 1000000000 /dev/urandom > urand.out
head -c 1000000000 /dev/urandom > urand.out 0.13s user 61.22s system 99% cpu 1:01.41 total
そして結果ファイル-（内側からランダムに見えます）：
$ ls -l
-rw-rw-r-- 1 siegel siegel 1000000000 Aug 5 03:02 sharand.out
-rw-rw-r-- 1 siegel siegel 1000000000 Aug 5 03:11 urand.out
「合計」時間の値を比較すると、sharandは、urandomメソッドがGB未満のランダムバイトを作成するのに必要な時間の3分の1しかかかりませんでした。
sharand：合計22秒urandom：合計61秒
Linuxで特別なファイルが必要な場合、/ dev/randomはLinuxシステムで乱数ジェネレータとして機能します。/dev/randomは、システムに多くのアクティビティがない限り、最終的にブロックします。/dev/urandomは非ブロックです。ファイルを作成するときにブロックしたくないので、/ dev/urandomを使用します。
このコマンドを試してください：
dd if=/dev/urandom bs=1024 count=1000000 of=file_1GB conv=notrunc
これにより、ランダムなバイト数bs * countのファイルが作成されます。この場合、1024 * 1000000 = 1GBです。ファイルには読み取り可能な内容は含まれていませんが、改行がいくつか含まれています。
xKon@xK0n-ubuntu-vm:~/tmp$ dd if=/dev/urandom of=file.txt bs=1048576 count=100 conv=notrunc
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 13.4593 s, 7.8 MB/s
xKon@xK0n-ubuntu-vm:~/tmp$ wc -l file.txt
410102 file.txt
オプションddでseekを使用すると、プロセスをもう少し高速化できます。
$ dd if=/dev/zero of=1g.img bs=1 count=0 seek=1G
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 8.12307 s, 132 MB/s
$ ls -lh t
-rw-rw-r-- 1 xK0n xK0n 1.1G 2014-08-05 11:43 t
ここでの欠点は、ファイルに読み取り可能なものが含まれていないこと、および/ dev/zeroメソッドよりもかなり遅い（100Mbで約10秒）ことです。
また、ファイルにスペースを事前に割り当てるfallocateコマンドもお勧めです。
fallocate -l 1G test.img
出力
-rw-r--r--。 1 xK0n xK0n 1.0G Aug 05 11:43 test.img