Apenas a resposta até agora é da Nils - mas, de acordo com os meus comentários, há os dispositivos iRAM e hyperdrive. Então eu vou fechar isso
Eu estive pensando em maneiras de acelerar o disco de E / S, e um dos gargalos que eu continuo voltando é o diário. Há um benefício óbvio em usar um SSD para o periódico - além de apenas gravar o cache a menos que, é claro, eu apenas desative o diário com o cache de gravação (afinal, o devicemapper não parece suportar barreiras). A fim de obter os benefícios de usar um cache de gravação BB no controlador, eu precisaria desativar o journalling - mas, em seguida, o sistema operacional deve tentar fsck o sistema após uma interrupção. É claro que se o sistema operacional souber o que há na memória com suporte a bateria, ele poderá usá-lo como no diário - mas isso significa que ele deve ser exposto como um dispositivo de bloco e estar sob controle do sistema operacional .
No entanto, não consegui encontrar um dispositivo adequado de baixo custo (não, o nivelamento de gravação para o Flash não é adequado para um diário, pelo menos um que use Smartmedia ).
Embora não haja nenhum fim de dispositivos flash, controladores de disco / matriz com caches de gravação BB, até agora não encontrei nada que apenas me dê memória não volátil endereçável como um dispositivo de armazenamento em bloco.
Você poderia explicar por que há uma vantagem óbvia usando SSDs para periódicos? Todos os FS implementam diários como algum tipo de buffer de anel onde o acesso é sequencial de qualquer maneira. Apenas desative barreiras em BBWCs e é tão bom quanto é possível.
Sistema de arquivos EXT3 e EXT4 usado para montar com um jornal no modo 'ordenado'. Nos Kernels mais recentes, o padrão é o modo 'write-back'. No modo 'ordenado', as atualizações de diário foram confirmadas no disco antes que qualquer dado fosse gravado. No modo 'write-back' as atualizações de diário são gravadas no disco de acordo com as políticas normais do agendador de I / O e as gravações de dados no disco não são bloqueadas nas atualizações do diário. Você basicamente não vê que há um diário envolvido no POV de desempenho.
O que você quer é desabilitar barreiras (e provavelmente mascarar os CDBs FUA e SCSI_CACHE_SYNCHRONIZE SCSI) em qualquer coisa que possa proteger suas gravações por bateria, caso contrário seu desempenho será prejudicado. Você obtém a semântica de barreiras (ou qualquer coisa que seja liberada para discos e aguarda reconhecimento) em seu diário e dados usando um BBWC.
Uma NVRAM sem o suporte adequado do sistema operacional (VFS) não vai ajudá-lo com qualquer coisa que o BBWC (que é algum tipo de NVRAM) não consiga resolver. No Linux 2.4, havia suporte para certos dispositivos NVRAM para acelerar o NFSv2 / 3 que está sendo executado de forma síncrona, mas os BBWCs os tornaram obsoletos.
A melhor coisa a fazer com os dispositivos flash é não pensar neles como um dispositivo de bloco e usá-los como eles são - flash NAND. Mas isso precisaria de um novo design de como achamos que um sistema de arquivos deve se comunicar com o armazenamento subjacente de uma maneira mais genérica. Também não há uma API adequada no Kernel para usar o flash NAND no momento.As unidades SSD não devem ser usadas para operações de gravação frequentes. Por que você não simplesmente coloca o diário em um sistema RAID à prova de falhas (5 ou 10) que consiste em discos comuns (pelo menos 4 "pequenos")?
Tags hard-drive linux journal