É possível usar hard links entre conjuntos de dados NAS separados?

Não. Uma ligação rígida tem de referenciar o mesmo inode dentro de um sistema de ficheiros; conjuntos de dados ou montagens separados normalmente devolvem EXDEV.

A decisão é importante quando um fluxo de trabalho de organização ou deduplicação pretende que um ficheiro apareça em bibliotecas armazenadas em conjuntos de dados NAS separados. Os dois estados concorrentes são ligação rígida no mesmo sistema de ficheiros e cópia, reflink, clone ou referência da aplicação entre sistemas de ficheiros. Comece com uma configuração guardada e dados descartáveis, observe um ramo de cada vez e pare se o teste aumentar o risco de perda de dados, permissões ou disponibilidade.

Definir as condições subjacentes à decisão sobre ligações rígidas entre conjuntos de dados

Registe o ambiente antes de alterar qualquer coisa: versões do software e do firmware, identidades dos dispositivos, caminho de montagem ou de rede, espaço livre, permissões e o sintoma observável. A linha de base deve conservar detalhes suficientes para reproduzir um fluxo de trabalho de organização ou deduplicação que pretenda que um ficheiro apareça em bibliotecas armazenadas em conjuntos de dados NAS separados.

O primeiro candidato é uma ligação rígida no mesmo sistema de ficheiros. O segundo é uma cópia, reflink, clone ou referência da aplicação entre sistemas de ficheiros. O link system call limits atual define o mecanismo ou limite de comando utilizado no teste; não substitui a observação neste servidor doméstico específico.

Escreva a condição de aceitação e a condição de paragem antes de executar o discriminador. Um resultado positivo deve alterar as evidências previstas por um dos ramos, mantendo inalterados os serviços não relacionados; um resultado negativo deve devolver o sistema ao estado guardado, em vez de desencadear uma cadeia de correções especulativas.

Testar a afirmação sem reduzir o requisito original

Utilize este discriminador: compare os IDs dos dispositivos e tente criar uma ligação descartável em caminhos do mesmo conjunto de dados e de conjuntos de dados diferentes. Mantenha constantes a carga de trabalho, o cliente, o caminho, o conjunto de ficheiros e o momento, para que o resultado seja atribuído à variável alterada.

Utilize limites das ligações rígidas para selecionar o campo que pode realmente separar os ramos e, em seguida, registe o respetivo carimbo de data/hora, estado de saída, texto do erro, identidade do dispositivo ou do instantâneo, latência, bytes transferidos, permissões e estado de recuperação. Uma saída limpa do comando não é suficiente quando a identidade, a durabilidade ou o estado da aplicação constituem a afirmação em teste.

Repita o teste uma vez depois de um reinício, religação, remontagem ou cache fria quando esse evento fizer parte da condição original. Se a primeira execução for destrutiva ou não for possível restaurar o ambiente, pare e reproduza o teste numa cópia descartável.

stat -c "%d %i %h %n" source target
ln source cross-dataset-target

Interpretar resultados positivos, negativos e excecionais

POSITIVO: a ligação no mesmo conjunto de dados partilha o inode e a contagem de ligações, enquanto a tentativa entre conjuntos de dados falha sem alterar os dados. Registe a versão, a identidade e a carga de trabalho exatas que produziram o resultado positivo, para que a conclusão permaneça condicional em vez de se tornar uma afirmação universal.

NEGATIVO: uma ferramenta copia silenciosamente em vez de criar uma ligação, ou as montagens bind ocultam o verdadeiro limite do sistema de ficheiros. Um resultado negativo não prova automaticamente o ramo oposto quando a rede, a memória, as permissões ou a consistência da origem podem influenciar ambos; isole essas dependências partilhadas antes de escalar.

RESULTADO EXCECIONAL OU AMBÍGUO: utilize uma cópia explícita, um reflink suportado ou redesenhe os limites dos conjuntos de dados com base nas necessidades de retenção. Preserve os registos e não execute comandos de reparação, limpeza, destruição, reparticionamento ou alteração recursiva de proprietários até existir uma cópia recuperável.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirmar a decisão com a carga de trabalho original

Aplique a ação correspondente ao ramo observado e, em seguida, repita a condição original em vez de um substituto reduzido. A decisão só é válida quando a ligação no mesmo conjunto de dados partilha o inode e a contagem de ligações, enquanto a tentativa entre conjuntos de dados falha sem alterar os dados durante dois ciclos ou após o reinício, suspensão, interrupção ou transição de carga relevante.

Utilize o mapeamento de identidades NFS para verificar o fluxo de trabalho dependente mais próximo, mas mantenha inalterado o acionador original. Os conjuntos de dados, partilhas, contentores, utilizadores e pontos de recuperação não relacionados devem manter o acesso e o tempo de resposta anteriores.

O limite de paragem é explícito: se uma ferramenta copiar silenciosamente em vez de criar uma ligação ou se as montagens bind ocultarem o verdadeiro limite do sistema de ficheiros, volte à última configuração verificada, conserve as evidências e escale para um teste mais aprofundado da plataforma ou do hardware apenas quando o ramo for reproduzível.

Depois de o resultado pretendido se manter, compare-o com o mapeamento de UID de contentores, para que a correção não transfira o risco para um serviço vizinho. Um teste-alvo bem-sucedido acompanhado por uma nova falha de cópia de segurança, identidade, tempo limite ou disponibilidade continua a ser uma alteração falhada.

FAQ

No caso de ligações rígidas entre conjuntos de dados, as pesquisas restantes normalmente dizem respeito a saber se uma montagem bind pode possibilitar ligações rígidas entre conjuntos de dados, se as ligações simbólicas são permitidas entre conjuntos de dados e se os reflinks podem substituir ligações rígidas. As respostas abaixo mantêm esses casos extremos separados da decisão principal.

O limite de aceitação não muda: a ligação no mesmo conjunto de dados partilha o inode e a contagem de ligações, enquanto a tentativa entre conjuntos de dados falha sem alterar os dados. Se uma condição posterior alterar o sistema de ficheiros, a identidade, o caminho de rede ou a versão da aplicação, repita apenas o discriminador afetado por essa alteração.

Pare de alargar a experiência quando uma ferramenta copiar silenciosamente em vez de criar uma ligação ou quando as montagens bind ocultarem o verdadeiro limite do sistema de ficheiros. Nesse momento, utilize uma cópia explícita, um reflink suportado ou redesenhe os limites dos conjuntos de dados com base nas necessidades de retenção; preserve as evidências antes de escalar para o responsável pela plataforma, pelo armazenamento ou pelo hardware.

Uma montagem bind pode possibilitar ligações rígidas entre conjuntos de dados?

Não. Altera a perspetiva do caminho, não a identidade subjacente do sistema de ficheiros.

São permitidas ligações simbólicas entre conjuntos de dados?

Sim, mas armazenam um caminho e não preservam os dados se o destino desaparecer.

Os reflinks podem substituir ligações rígidas?

Nos sistemas de ficheiros suportados, partilham inicialmente os blocos, mas tornam-se ficheiros independentes quando são modificados.

Para ligações rígidas entre conjuntos de dados, a resposta prática continua a ser condicional: a ligação no mesmo conjunto de dados partilha o inode e a contagem de ligações, enquanto a tentativa entre conjuntos de dados falha sem alterar os dados. Quando uma ferramenta copia silenciosamente em vez de criar uma ligação ou as montagens bind ocultam o verdadeiro limite do sistema de ficheiros, utilize uma cópia explícita, um reflink suportado ou redesenhe os limites dos conjuntos de dados com base nas necessidades de retenção; um sucesso parcial que não consiga resistir à carga de trabalho original não é compatibilidade.