É seguro ignorar O_DIRECT?

Question

Vou implementar um sistema de arquivos no FUSE e depois no kernel. Não tenho certeza do que fazer com o Direct IO. Diferentes fontes enfatizam coisas diferentes que esta bandeira supostamente implica.

É seguro que um sistema de arquivos simplesmente ignore O_DIRECT?

• As operações de leitura e gravação prosseguiriam normalmente. Open iria ignorá-lo e não falhar.
• As somas de verificação de dados ainda seriam verificadas. Portanto, uma operação de leitura pode falhar devido à soma de verificação, mesmo que o disco rígido retorne OK.
• Os dados escritos estariam sujeitos a cópia na gravação e na alocação atrasada.
• As operações de gravação retornariam OK imediatamente. Writeback aconteceria após um atraso, ou nunca em caso de falta de energia. A durabilidade não é garantida, mas isto é O_SYNC sementic de qualquer maneira.

Poucas questões vêm à mente.

• O armazenamento em cache do conteúdo do arquivo no cache Buffer / Page é, no meu entender, uma responsabilidade do VFS e não do sistema de arquivos. O VFS também interpreta esse sinalizador?
• De acordo com uma resposta , o sinalizador pode falhar em kernels futuros. Comentário sob a resposta explica que o Direct IO é contrário ao modo de registro de dados de dados.

Answer 1

Na página de manual open(2) :

   O_DIRECT (since Linux 2.4.10)
          Try to minimize cache effects of the I/O to and from this
          file.  In general this will degrade performance, but it is
          useful in special situations, such as when applications do
          their own caching.  File I/O is done directly to/from user-
          space buffers.  The O_DIRECT flag on its own makes an effort
          to transfer data synchronously, but does not give the
          guarantees of the O_SYNC flag that data and necessary metadata
          are transferred.  To guarantee synchronous I/O, O_SYNC must be
          used in addition to O_DIRECT.  See NOTES below for further
          discussion.

Na seção NOTES:

   O_DIRECT support was added under Linux in kernel version 2.4.10.
   Older Linux kernels simply ignore this flag.  Some filesystems may
   not implement the flag and open() will fail with EINVAL if it is
   used.

Então O_DIRECT costumava ser simplesmente ignorado. E do LKML , há alguns meses:

Who cares how a filesystem implements O_DIRECT as long as it does not corrupt data? ext3 fell back to buffered IO in many situations, yet the only complaints about that were performance. IOWs, it's long been true that if the user cares about O_DIRECT performance then they have to be careful about their choice of filesystem.

But if it's only 5 lines of code per filesystem to support O_DIRECT correctly via buffered IO, then exactly why should userspace have to jump through hoops to explicitly handle open(O_DIRECT) failure?

Especially when you consider that all they can do is fall back to buffered IO themselves....

     

Eu escrevi contrapontos para tudo isso, mas achei melhor   isto. Versões antigas do kernel simplesmente ignoram O_DIRECT, tão claramente   há precedente.

Dado que, parece que você está seguro simplesmente ignorá-lo. A frase chave parece ser "não corromper dados".

Por enquanto.

Note também que sua pergunta vinculada tem respostas que dizem O_DIRECT não é útil por motivos de desempenho. Isso é simplesmente incorreto. Passar dados através do cache da página é mais lento do que não passando através do cache da página. Isso pode ser significativo em hardware capaz de transferir gigabytes por segundo. E se você manejar apenas cada bit de dados uma vez, o cache é literalmente inútil, mas afetará desnecessariamente todo o sistema.

Faz alguns anos que eu escrevi um módulo de sistema de arquivos Linux. Infelizmente, não me lembro de como os sistemas VFS lidam com o armazenamento em cache.