Gerar uma grande quantidade de dados pseudo-aleatórios previsivelmente

Question

Eu comprei HDDs de 2 TB (60 € cada) e quero verificar se eles retornam os dados que foram alimentados ao ler antes de usá-los. Eu chequei alguns pen drives, copiando arquivos grandes que eu tinha por aí e checando os hashes dos dados que eles devolveram (e encontrei aqueles que simplesmente jogavam dados fora depois que a capacidade real de armazenamento estava esgotada). Infelizmente, não tenho nenhum arquivo de 2 TB por aí.

Agora quero gerar 2 TB de dados pseudo-aleatórios, gravá-los nos discos e obter um hash dos discos. Eu então quero escrever os mesmos dados diretamente para a função hash e obter o hash que ele deve produzir dessa maneira. A função pseudo-aleatória não precisa ser criptograficamente segura de qualquer forma, ela só precisa produzir dados com alta entropia rápida.

Se eu escrever um script que apenas hashes uma variável contendo um número, imprime o hash para stdout, incrementa a variável e repete, a taxa de dados é muito lenta, mesmo quando usando uma CPU rápida. Como 5 ordens de magnitude muito lentas (nem mesmo 60 kByte / s).

Agora, eu poderia tentar fazer isso com tee , mas parece uma péssima ideia e não consigo reproduzir os mesmos dados repetidas vezes.

Idealmente, eu passaria algum argumento curto (um número, uma cadeia de caracteres, não importa) para o programa e obteria uma quantidade arbitrariamente grande de dados em seu stdout, e esses dados seriam os mesmos em cada chamada. .

    

Answer 1

Bem, a maioria das pessoas usa apenas badblocks ...

Caso contrário, basta criptografar zeros. Criptografia faz exatamente o que você quer. Zeros criptografados se parecem com dados aleatórios. Decifrar dados aleatórios os transforma em zeros. É determinista, reversível, desde que você conheça a chave.

cryptsetup open --type plain --cipher aes-xts-plain64 /dev/yourdisk cryptodisk
shred -n 0 -z -v /dev/mapper/cryptodisk # overwrites everything
cmp /dev/zero /dev/mapper/cryptodisk    # byte-by-byte comparison

Isso deve utilizar a velocidade total do disco em um sistema moderno com o AES-NI.

Também funciona apenas para canalizar (sem o armazenamento real)

cd /dev/shm # tmpfs
truncate -s 1E exabyte_of_zero
losetup --find --show --read-only exabyte_of_zero
cryptsetup open --type plain --cipher aes-xts-plain64 --readonly /dev/loop4
cat /dev/mapper/loopcrypt | something_that_wanted_random_data

ou se ainda estivermos gravando em um disco e comparando

cat /dev/mapper/loopcrypt > /dev/sdx
# overwrites until no space left on device
cmp /dev/mapper/loopcrypt /dev/sdx
# compares until EOF on /dev/sdx OR loopcrypt and sdx differ byte X.

Ao contrário do PRNG, isso também pode ser usado para começar a comparar dados em algum lugar no meio do arquivo. Com um PRNG tradicional, você tem que gerá-lo novamente para voltar a qualquer posição em que estivesse interessado. Claro, você poderia fazer uma semente aleatória baseada em offset ou algo assim ...

    

Answer 2

Se você tem tanto medo de integridade de dados, então use ex .: ZFS, ele tem verificação de integridade embutida, já que um novo HW pode ser ok, mas anos mais tarde podem se tornar ruins.

link

Here’s something you never want to see:

ZFS has detected a checksum error:

   eid: 138
 class: checksum
  host: alexandria
  time: 2017-01-29 18:08:10-0600
 vtype: disk

This means there was a data error on the drive. But it’s worse than a typical data error — this is an error that was not detected by the hardware. Unlike most filesystems, ZFS and btrfs write a checksum with every block of data (both data and metadata) written to the drive, and the checksum is verified at read time. Most filesystems don’t do this, because theoretically the hardware should detect all errors. But in practice, it doesn’t always, which can lead to silent data corruption. That’s why I use ZFS wherever I possibly can.