Tenho um novo sistema de arquivos em mente, mas a estrutura torna impossível implementar mais de um link físico para cada inode. ("." e ".." são tratados de forma diferente.)
Ele não foi criado para ser um sistema de arquivos raiz, mas pode ser usado como um sistema de arquivos de uso geral em /home, etc.
Links físicos são comumente usados fora dos diretórios do sistema (Linux)?
Quais problemas os usuários podem sofrer se não tiverem suporte para links físicos?
Sim; mas também, se eles são ou não é um ponto discutível: usuários de sistemas Linux modernos não querem ser surpreendidos porque seus contêineres/flatpaks/snaps/toolbx'es não funcionam em seu sistema de arquivos home. Você precisa ser capaz de suportar tudo o que um sistema de arquivos root faz em /home.
Falta de habilidade para executar as tecnologias mencionadas acima. No meu exemplo pessoal, nem flatpak nem podman funcionariam, que são ferramentas que eu uso diariamente, porque, no mínimo, o empacotamento do zoneinfo do tzinfo em múltiplas imagens base depende de hardlinks, alguns
__pycache__mecanismos python dependem de hardlinks e, geralmente, a sobreposição de imagens de contêiner depende.(Observe também que, pelo menos quando presentes para o usuário, as entradas
.e.., que devem ser visíveis (não necessariamente armazenadas explicitamente) em cada diretório, precisam se comportar como links físicos para o mesmo diretório e seu diretório pai, respectivamente.Stephen aponta que o seguinte não é verdade no btrfs: Isso tem um efeito muito direto: a contagem de hard links de cada diretório é 2 + o número de diretórios contidos no diretório. Se seu sistema de arquivos não implementar isso, ele se comportará mal, porque as ferramentas não saberão o número de subdiretórios de um diretório.)