Eu tenho uma imagem na minha cabeça onde um link é muito lento para perceber a transferência em tempo real dos arquivos, mas rápido o suficiente para recuperar todos os dias. O que eu gostaria de ver é um mestre < - > setup mestre onde quando eu escrevo um arquivo para o Servidor A, os metadados serão transferidos para o Servidor B imediatamente e o arquivo será transferido em estado ocioso ou imediatamente quando o cliente do Servidor B tentar ler o arquivo antes que o Servidor A o envie.
Parece que existem muitos sistemas de arquivos que podem funcionar bem em links rápidos, mas eu não conheço nenhum que faça bem com um grande gargalo e algumas horas de latência.
glusterfs tem um modo de cura que funciona como você descreve; ele compartilha metadados, mas apenas "cura" as cópias dos arquivos no acesso. O processo de "sincronização noturna" foi documentado como:
find /mountpoint -type f -print0 | xargs -0 head -c1
Aviso: Espero que esse recurso específico ainda esteja disponível, mas não o usei em um ano.
Soooo ... o problema que você tem aí é o que você faz quando alguém do lado A quer um arquivo que foi escrito no lado B, mas ainda não foi sincronizado?
Existe uma razão pela qual sistemas de arquivos compartilhados que funcionam bem em links rápidos são comuns - é possível definir semânticas padrão para sua operação que mapeiam razoavelmente bem a semântica padrão do sistema de arquivos POSIX que todos nós conhecemos e amamos. Qualquer coisa em que nem todos os dados estejam realmente disponíveis cai praticamente imediatamente no território "específico do domínio" - seu caso de uso para um sistema de arquivos que não precisa se preocupar com dados está faltando (um armazenamento de dados apenas anexado apenas, por exemplo, ou um onde você pode lidar com dados perdidos efetivamente recalculando-os ou falsificando os resultados), mas essas não são situações bastante comuns (e são muito difíceis de modelar, especificar, etc) tal que ninguém se preocupou em escrever algo que todos possam usar.