por favor, explique os resultados do meu fio - o O_SYNC | O_DIRECT está se comportando mal no linux?

1

Estou ficando louco por descobrir qual poderia ser o problema com uma de nossas caixas de armazenamento. Com um script de fio simples, estou testando gravações aleatórias usando bs = 1M e direct = 1. O SSD é um 840pro da Samsung ligado a um LBA HBA (portas 3Gbit / s).

Este é o resultado que estou recebendo no FreeBSD 9.1:

WRITE: io=13169MB, aggrb=224743KB/s, minb=224743KB/s, maxb=224743KB/s, mint=60002msec,   maxt=60002msec

Isso ocorre independentemente da sincronização ser definida como 0 ou 1.

No linux, este é o resultado com sync = 0:

WRITE: io=14828MB, aggrb=253060KB/s, minb=253060KB/s, maxb=253060KB/s, mint=60001msec, maxt=60001msec

e com sync = 1:

WRITE: io=6360.0MB, aggrb=108542KB/s, minb=108542KB/s, maxb=108542KB/s, mint=60001msec, maxt=60001msec

Meu entendimento é que, como estou operando no dispositivo de bloco bruto, O_SYNC não deve fazer nenhuma diferença - não há sistema de arquivos, nenhuma barreira, nada entre as gravações e a própria unidade. Especialmente com o conjunto O_DIRECT | O_SYNC.

Alguma idéia?

Para referência, aqui está o script de fio com o qual estou testando:

[global]
bs=1M
ioengine=sync
iodepth=4
size=16g
direct=1
runtime=60
filename=/dev/sdh
sync=1

[rand-write]
rw=randwrite
stonewall
    
por Zoltan 02.07.2013 / 11:52

1 resposta

3

O desenvolvedor do Kernel do Linux, Christoph Hellwig, respondeu ao Zoltan por e-mail sobre o O_SYNC em dispositivos de blocos do Linux :

For consumer disks using O_SYNC on Linux does make a huge difference, because it flushes the disk write cache after completion to make sure the O_SYNC gurantees that data has hit physical storage are met.

It seems like FreeBSD might be missing that call.

    
por 30.03.2014 / 09:29