Por que escrever SLOW no dispositivo bruto e FAST no sistema de arquivos (chave USB)?

Question

Eu tenho uma chave USB ( PQI U822V-Speedy 32G ) que eu estou tentando benchmark quick'n'dirty no Linux. Estou testando escrever banda.

dd na partição bruta

Eu criei uma partição a partir do setor 2048 e fiz uma gravação sequencial de 4 GB:

dd if=/dev/zero of=/dev/sdb1 bs=1M count=4096

Eu recebo ~ 22 MB / s.

Eu também tentei vários (4) dd rodando em paralelo como o acima, mas usando count=1024 e a opção seek= para gravar em diferentes áreas da unidade. Mesmos resultados

dd no sistema de arquivos

No entanto, quando formatar a partição sdb1 com ext4 ou NTFS e copie arquivos grandes para ela (seja real ou /dev/zero ), assim:

time dd if=/dev/zero of=/media/USBKEY/file.bin bs=1M count=4096 ; time sync

Eu alcanço > 66 MB / s como anunciado pelo fabricante. Naturalmente, considerei a duração de sync logo após a cópia.

Por que existe uma diferença de desempenho tão grande?

    

Answer 1

Agora que eu olho novamente, percebi que você disse que esta era uma chave USB (unidade flash) e não um disco rígido. A memória flash só pode ser apagada em grandes blocos, e setores individuais não podem ser gravados sem apagá-los (e o bloco inteiro em que estão) primeiro. Como o software espera poder gravar onde quer que esteja no disco a qualquer momento, o disco possui uma lógica de conversão para lidar de forma transparente com o apagamento. Como isso é feito tem um efeito dramático no desempenho de gravação. Muitos dispositivos usam um algoritmo para a maior parte do disco que lida com gravações sequenciais muito bem, mas é uma droga em gravações aleatórias. A área perto do início do disco é normalmente usada pelo FAT no sistema de arquivos FAT com o qual eles vêm pré-formatados, e essa área é escrita aleatoriamente com freqüência, então eles usam um algoritmo diferente nessa área que é mais lento em gravações sequenciais, mas não terrível ao acaso escreve.

Assim, agora tenho certeza de que meu palpite inicial que adicionei como comentário foi correto. O que você está vendo quando grava no sistema de arquivos é o desempenho do resto do disco, e quando você desce no zero, você está gravando na área de gordura. Se você procurar o destino dd algumas centenas de mb, ele deve acelerar consideravelmente.

    

Answer 2

Seus resultados de medição podem ser explicados com a arquitetura do kernel. Usar o acesso ao sistema de arquivos irá liberar todo o potencial do kernel com todos os buffers e otimizações que ele pode fazer. Especialmente os buffers irão acelerar o seu benchmark (b / c o kernel é 100% a_A_syncronous). dd em um arquivo de dispositivo não usa muito / muito disso.

    

Answer 3

Tente usar hdparm para comparar o desempenho de uma unidade com e sem usar qualquer cache:

$ sudo hdparm -tT /dev/sda1

/dev/sda1:
 Timing cached reads:   6314 MB in  2.00 seconds = 3157.61 MB/sec
 Timing buffered disk reads: 244 MB in  3.04 seconds =  80.26 MB/sec

    

Answer 4

Isso acontece devido à otimização de escrever arquivos esparsos no sistema de arquivos.

Quando você executa dd if=/dev/zero no dispositivo bruto, os blocos zero são gravados no disco.

No entanto, quando você os grava em um arquivo, o sistema de arquivos ignora a gravação dos dados e salva apenas os metadados. Isso resulta em muito poucos blocos sendo gravados no disco. O arquivo pode ser visto como um grande buraco, que não contém nada.

Para testar o desempenho dessa maneira, use / dev / urandom como arquivo de entrada ( dd if=/dev/urandom ). Isso forçará o sistema de arquivos a gravar dados aleatórios no disco.