A questão é um pouco ampla e pouco clara. Eu não estou familiarizado com essa ferramenta "fio" que você menciona, e uma rápida olhada na sua página da web não revelou detalhes sobre como funciona (ou seja, o que está medindo).
- Como duDE disse, em princípio, o tempo de busca - o tempo necessário para mover a (s) cabeça (s) de E / S do cilindro onde eles estão para o cilindro onde você quer fazer uma operação de I / O - deve ser independente da operação que você quer fazer no cilindro alvo. Eu acredito que isso é comum para um driver de disco emitir dois comandos separados - procure e leia, ou procurar e depois escrever - então o disco nem sequer sabe seja uma busca por leitura ou uma busca por escrita.
Mas, como eu disse no meu primeiro parágrafo, não sei o que "fio" está medindo. Eu não sei como um programa pode medir o tempo real de busca sem ter sondas de kernel. Pode estar medindo o tempo para uma operação de E / S no nível da API.
- Mesmo no nível do hardware, uma operação de gravação pode ser automaticamente seguida por uma leitura dos mesmos dados, para verificar a exatidão.
- No nível do hardware, se você tiver armazenamento redundante (como o RAID), onde os mesmos dados são mantidos em dois ou mais drives independentes, Normalmente, a cabeça de E / S em uma unidade tenderá a permanecer em um cilindro de numeração baixa (por exemplo, 0,25 × MAXCYL), enquanto a cabeça de E / S na outra unidade tenderá a permanecer num cilindro de numeração elevada (por exemplo, 0,75 x MAXCYL). Uma operação de leitura vai para a unidade cuja cabeça está mais perto do cilindro alvo, então o máximo que precisará procurar será 0,25 × MAXCYL, enquanto a operação de gravação irá para ambas as unidades, então pode ser necessário buscar até 0,75 × MAXCYL.
-
No nível do sistema operacional / sistema de arquivos,
- Uma leitura pode ou não atualizar o tempo de acesso de um arquivo. Alguns sistemas desativam isso completamente. Outros podem apenas definir uma bandeira (por exemplo, no inode residente na memória relevante, ou equivalente) que o arquivo foi lido; o inode residente no disco pode não ser atualizado até algum tempo depois (de forma assíncrona).
-
Uma gravação
- provavelmente exigirá a atualização do horário de modificação do arquivo.
- Se você estiver estendendo o arquivo
(em vez de apenas sobrescrever os dados próximos do final),
- exigirá que o tamanho do arquivo seja alterado (por exemplo, no inode) e
- pode exigir alocação de bloco (s) da lista livre (ou equivalente),
e provavelmente não será possível adiar essas atividades.
- Se você estiver usando um arquivo antigo para o seu teste, e você desfragmentou o disco desde que o arquivo foi criado, mas você estendeu o arquivo desde então (mesmo que você não esteja estendendo o arquivo nesses testes), pode ser que o começo do arquivo esteja armazenado em uma região contígua, e o final do arquivo não é. Mas a única implicação que posso ver disso é que acessar a frente do arquivo pode ser mais rápido do que acessar o final. Não vejo como isso possa causar uma diferença entre ler e escrever.