Object Storage Service:Configure um diretório temporário local para suportar gravações aleatórias

Informações básicas

Após a criação de um objeto no OSS, não é possível modificá-lo parcialmente. Qualquer alteração de conteúdo exige a substituição integral do objeto. No modo padrão do ossfs 2.0, o caminho de gravação utiliza upload em streaming: os dados são enviados ao OSS em partes sequenciais à medida que são gravados, o que impõe as seguintes limitações:

• Suporte apenas a gravações sequenciais. Chamadas pwrite em posições além do final do arquivo não são suportadas.

• A operação truncate suporta apenas truncamento para 0. Truncar para qualquer outro tamanho diferente de zero retorna ENOTSUP.

• Impossibilidade de ler um arquivo durante a gravação (antes do fechamento). Essa tentativa retorna EBUSY.

Cenários como execução de código por agentes de IA, edição de scripts no local e resultados intermediários de computação científica dependem frequentemente de semântica de gravação aleatória. O recurso de gravação aleatória do ossfs 2.0 armazena os dados gravados em um diretório temporário local e, combinado com gerenciamento de chunks e upload incremental, implementa gravações aleatórias sobre o armazenamento de objetos.

O modo de gravação aleatória do ossfs 2.0 apresenta as seguintes características:

• Semântica completa de gravação aleatória POSIX: Suporta pwrite em offsets arbitrários, O_APPEND e truncate para qualquer tamanho (aumento ou redução).

• Leitura durante a gravação: Permite ler um arquivo enquanto ele está sendo gravado. As partes modificadas são lidas da área de staging local, e as partes não modificadas são lidas diretamente do OSS.

• Upload incremental: Em operações de flush ou close, apenas os blocos de dados modificados são enviados do disco local. As partes inalteradas são tratadas via cópia no lado do servidor no OSS, sem I/O local e sem consumo de largura de banda de upload.

• Proteção de espaço em disco: Um orçamento global de disco integrado retorna ENOSPC para gravações quando o disco de staging estiver com pouco espaço. Reserve um limiar de espaço livre no momento da montagem para evitar que o disco do sistema seja preenchido totalmente.

Princípios de funcionamento

Métodos de configuração

Restrições:

• Se o diretório apontado por --temp_dir não existir, ele será criado automaticamente. Recomendamos usar uma partição ou disco independente para evitar disputa de espaço com o disco do sistema ou outras cargas de trabalho.

• Os dados dos arquivos em gravação são armazenados no diretório temporário local. Se o disco não tiver capacidade suficiente, as gravações retornam ENOSPC. O espaço livre restante em disco menos o espaço reservado por temp_dir_free_bytes é denominado espaço em disco gravável. O ossfs2 usa apenas essa porção de espaço para armazenar dados em gravação. O espaço em disco gravável deve ser maior que o tamanho total de todos os arquivos sendo gravados simultaneamente (no pior caso, um arquivo inteiro pode ser gravado localmente).

• Quando várias instâncias do ossfs2 são montadas na mesma máquina, elas podem compartilhar o mesmo diretório temporário, pois os nomes dos arquivos de staging não colidem. No entanto, múltiplas instâncias disputarão o espaço e o I/O do disco, portanto recomendamos o uso de diretórios independentes.

• As opções --temp_dir e --enable_appendable_object são mutuamente exclusivas e não podem ser ativadas simultaneamente.

Exemplo de comando de montagem:

ossfs2 mount /mnt/oss/ \
  --oss_bucket <your-bucket> \
  --oss_endpoint <your-endpoint> \
  --oss_access_key_id <ak> \
  --oss_access_key_secret <sk> \
  --temp_dir /mnt/disk/ossfs2/temp \
  --temp_dir_free_bytes 1G

Requisitos de ambiente

Efeitos do recurso

Comparação das capacidades de gravação antes e depois de ativar --temp_dir:

Semântica de durabilidade:

• Por padrão, o modo de gravação aleatória segue a semântica de fsync: fsync dispara um upload mesclado das modificações locais com os dados na cloud. Um retorno bem-sucedido significa que os dados foram persistidos no OSS. Os dados restantes também são enviados quando o arquivo é fechado.

• Uma falha de upload é retornada à aplicação como erro, e a aplicação pode tentar novamente via fsync. Se o upload falhar definitivamente e o arquivo for fechado, os dados não persistidos são perdidos, e o conteúdo do arquivo reverte para a última versão enviada com sucesso no lado remoto.

• Se o processo encerrar anormalmente, os dados em staging não enviados são perdidos, mas o objeto no OSS permanece no estado do último upload bem-sucedido. Nenhum objeto corrompido é gerado.

Recomendações de uso

Gravações aleatórias baseadas em um diretório temporário local são adequadas para cenários que exigem semântica de gravação semelhante à de um sistema de arquivos local em um ponto de montagem OSS.

Cenários adequados para ativar gravações aleatórias:

Cenários onde não se recomenda ativar gravações aleatórias:

Recomendações de orçamento de disco:

• Mantenha o diretório temporário separado do disco do sistema para evitar que os dados de staging preencham o disco do sistema e afetem a estabilidade do host. Se a máquina possuir apenas um disco, recomendamos definir temp_dir_free_bytes com um valor maior (por exemplo, 10G) para reservar espaço livre suficiente para o sistema.

• O espaço em disco gravável (consulte as restrições acima) deve ser maior que o tamanho total dos arquivos sendo gravados simultaneamente.

• Para um único arquivo maior que 100 GiB, além de aumentar explicitamente --random_write_max_file_size (por exemplo, --random_write_max_file_size=500G), garanta que o espaço em disco gravável exceda o tamanho desse arquivo.