Por que o número da unidade / partição ainda é usado?

Muitas vezes, especialmente quando se mexe com os gerenciadores de inicialização, eu vejo os números das unidades e das partições numéricas. Por exemplo, no meu ponto de /boot/grub/grub.cfgvista set root='hd0,gpt2', minhas entradas de inicialização UEFI geralmente fazem referência a números de unidades / partições e parecem surgir em praticamente qualquer contexto no que diz respeito aos gerenciadores de inicialização.

Agora que temos UUID e PARTUUID, abordar partições dessa maneira parece incrivelmente instável (depois que as unidades não são garantidas para serem montadas na mesma ordem sempre, um usuário pode mover a ordem das unidades que estão sendo conectadas ao seu mobo etc.)

Minhas perguntas, portanto, são duplas:

1. Esse esquema de endereçamento é tão instável quanto eu descrevi acima? Estou faltando algo no padrão que significa que esse esquema é muito mais confiável do que eu esperava, ou esse esquema de endereçamento realmente tornará seu sistema impossível de inicializar (até que você conserte suas entradas de inicialização pelo menos) como resultado de suas unidades serem simplesmente reconhecidas em um ordem diferente ou conectá-los em diferentes slots na sua placa-mãe?

2. Se a resposta à pergunta acima for sim, então por que esse esquema de endereçamento continua a ser usado? Usar UUID ou PARTUUID para tudo seria muito mais estável e consistente?

O esquema de numeração simples não é realmente usado em sistemas recentes (sendo "recente" o Ubuntu 9 e posterior, outras distribuições podem ter se adaptado nessa época também).
Você está correto ao observar que a partição raiz está definida com o esquema de numeração simples. Mas essa é apenas uma configuração padrão ou de reserva que geralmente é substituída pelo comando seguinte, como:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

Isso seleciona a partição raiz com base no UUID do sistema de arquivos.

Na prática, o esquema de numeração simples geralmente é estável (desde que não haja alterações de hardware). A única instância que observei numeração não previsível foi o sistema com muitas unidades USB, que foram enumeradas com base no padrão de primeiro a chegar, primeiro a ser servido, e depois emuladas como unidades IDE. Nenhum desses processos é inerentemente caótico, portanto, assumo um problema nessa implementação específica do BIOS do sistema.

Nota: "partição raiz", neste contexto, significa a partição para a qual inicializar; pode ser diferente da partição que contém o "sistema raiz / sistema de arquivos".

A rigor, o UUID não está endereçado .

O endereçamento é muito, muito simples: leia a unidade X do setor Y - ou então. Leia o endereço de memória Z - ou então. O endereçamento é simples, rápido, não deixa muito espaço para interpretação e está em toda parte.

UUID não está endereçando. Em vez disso, está pesquisando, localizando, às vezes aguardando a exibição dos dispositivos e também compreendendo os sistemas de arquivos (★). E, dependendo da quantidade de dispositivos, pode levar muito tempo. E uma vez encontrado, voltando ao endereço comum.

No GRUB, isso é chamado search(★★) e só está disponível quando o GRUB já possui asas (pesquisa é um módulo, assim como todos os sistemas de arquivos suportados, portanto, disponível apenas após o carregamento do núcleo). No Linux, é chamado (por exemplo) findfs, o findfs pesquisará os dispositivos de bloco no sistema procurando um sistema de arquivos ou partição .

Ele percorre todos os dispositivos de bloco, os acorda do modo de espera, lê os dados e o resultado ainda pode ser aleatório se o UUID não for único como deveria ser (após ddacidente ou algo semelhante) ou você não obtém resultado se o UUID for alterado. Os UUIDs também são propensos a erros de configuração.

Em geral, os UUIDs são ótimos e, é claro, você deve usá-los em qualquer lugar, se disponível, especialmente quando o endereçamento tradicional está fadado a falhar, porque a ordem das unidades é aleatória no Linux; mas entenda que a complexidade está acima e além do que o endereçamento simples deve fazer. E, especialmente, nos estágios iniciais dos gerenciadores de inicialização, talvez ainda não seja uma opção. O endereçamento vem em primeiro lugar, as asas em crescimento vêm depois.

Para o carregador de inicialização, talvez não seja necessário fazer um esforço (nem todo carregador de inicialização suporta uma ampla variedade de sistemas de arquivos como o GRUB). Se hd0é garantido que "é o disco do qual inicializamos" devido às circunstâncias (o BIOS fornece) e, portanto, se você puder descartar problemas aleatórios de ordem de unidade, pode não haver necessidade de percorrer uma lista potencialmente enorme de outras partições em procure por UUIDs.

Se você está confiante o suficiente em sua configuração para dizer que hd0,gpt2é o que deseja, e deve ser, e não pode ser de outra forma, não há nada de errado em usá-lo dessa maneira. Às vezes, o endereçamento simples e simples funciona perfeitamente.

(★) Eu expliquei isso anteriormente para LABELs aqui ...

Não existe um padrão genérico para etiquetas, é tudo tricotado manualmente; veja, por exemplo, esta implementação de formatos de superblocos no util-linux . Se você inventar um novo sistema de arquivos amanhã, mesmo que tenha um rótulo, ele não aparecerá até que o suporte seja adicionado.

... e é o mesmo para os UUIDs.

(★★) Na verdade, o GRUB's searchtem uma --hintopção e ... agora eu não verifiquei o código-fonte e nem sequer está documentado em seu manual, mas essa opção faria sentido para oferecer o melhor dos dois mundos: a dica deve informar searchpara verificar primeiro a partição e, se o UUID corresponder conforme o esperado, ele identificou o dispositivo com o mínimo esforço e, se não corresponder, ainda voltará à pesquisa completa para manter as coisas funcionando de alguma forma .

Além disso, os UUIDs encontrados anteriormente tendem a ser armazenados em cache, por isso não precisa passar por todos os dispositivos repetidas vezes - e isso também funciona muito bem, desde que o UUID que você está procurando realmente exista em algum lugar. faça isso no cache em primeiro lugar.

Também não se esqueça de etiquetas. Eles não são tão únicos quanto os UUIDs, mas muito mais informativos e tornam seu fstab legível por humanos. Se for sua área de trabalho ou uma empresa pequena - em outras palavras, você estiver gerenciando de algumas a algumas dezenas de unidades, talvez prefira rótulos aos UUIDs.

Pensando na excelente resposta de @ frostschutz à sua pergunta, um cenário em que você provavelmente preferiria o endereçamento de link de dispositivo "clássico" é a configuração da VM, especialmente nas nuvens VM para locação (abreviada, confusa, "IaaS"). Suponha que você queira personalizar uma imagem do Ubunzima 04.18 . Você cria uma VM (descartável) com 2 discos: um será a unidade do sistema (descartável) e o segundo será o que você montar e personalizar. Presumivelmente, você também monta sua partição de inicialização UEFI, se desejar criar um grub mais recente em seu novo disco. Supondo que você tenha escolhido pontos de montagem para as partições de destino abaixo /mnt, sua tabela de montagem desejada será semelhante a

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

Assim, você cria 2 unidades idênticas a partir da imagem existente, pronta para o provedor e pronta para a nuvem, conectando-as a uma nova VM e inicializando-a. Naturalmente,

• Todas as distribuições modernas de SO, nosso imaginário Ubunzima 04.18 não sendo uma exceção, dependem de montagens nomeadas por UUID.
• Todos os discos rígidos lançados a partir da mesma imagem têm o mesmo UUID. Os UUIDs são únicos, então o que poderia dar errado?

Você já vê para onde tudo isso está indo.

A primeira vez que a frankencontraption foi inicializada, ela foi escolhida sda9como partição de inicialização EFI, mas o Linux decidiu remontar sdb1como o FS raiz:

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

E como meu script de lançamento não estava preparado para isso, no final, tenho uma imagem de falha não inicializável, sem uma única ferramenta reclamando no registro durante o frankenbuild!

Claro que imprimi a tabela de montagem nos logs. E é claro que a bagunça é muito difícil de identificar, já que o mount (8) imprime montagens na ordem intermediária entre aleatória e aquela na qual os dispositivos foram montados, portanto, não foi surpresa que eu não tenha percebido imediatamente. E imagine que o mesmo script (mas com discos de imagens diferentes) funcionava tão suavemente quanto Glenfiddich, de 15 anos. Adivinhe quantas horas passei puxando meu cabelo¹ sobre o tronco tentando descobrir o problema?

Não há regras rígidas e rápidas que sejam boas para qualquer situação, de um PC de mesa a um Linux embutido em um roteador, ao telefone Android e a um data center na nuvem. Uma resposta do SO deve ser objetiva, e minhas experiências ou preferências, obviamente, não são. Então, prefiro mostrar exemplos de raciocínio lógico ao selecionar entre diferentes métodos de identificação de partições:

• Deixe em paz se você não tiver motivos para não fazê-lo. Os UUIDs são o padrão para as distribuições mais modernas. Se se trata de adicionar uma segunda unidade, tente e decida. Provavelmente, você nem precisará saber. Se o seu sistema ainda inicializar e você puder ver e particionar o novo dispositivo, formate e adicione-o ao fstab (por UUID, por LABEL ou por um /devlink, as mesmas considerações se aplicam). Somente quando seu sistema se recusa a inicializar após conectar a unidade extra, você tem um problema (e talvez alterar a ordem de inicialização no UEFI BIOS seja a saída mais rápida).

  Pragmaticamente, rotular qual conector SATA vai para qual unidade em sua própria área de trabalho pode ser a solução mais rápida e fácil, enquanto alterar a maneira como o sistema inicializa e se recuperar de uma falha de inicialização bastante provável é, sem dúvida, o pior tempo gasto. Mas se você o gerencia para 50 programadores que pensam que jogar em uma unidade extra não é um problema digno de incomodá-lo, pelo menos não teste os limites da sua sorte e verifique se as unidades de inicialização iniciais são vistas pelo grub como hd0e o sistema como sda.

• Etiquetas para gerenciar suas próprias unidades e partições em sua área de trabalho ou três, ou um pequeno ambiente (uma sala de estar de uma casa cheia de engenheiros de software que divertidamente chamam o local de "escritório de inicialização"). Se você puxa uma unidade física da máquina de alguém, sabe de onde veio se usar etiquetas de forma consistente.

  Se lsblk (8) diz LABEL=bubba-boot, você sabe que foi extraído da máquina chamada bubba ; além disso, a bota de borracha rola sobre minha língua muito mais facilmente do que 6864c4ea-f9b9-46db-b875-4d7fc2981007 , que, para meu gosto mimado, é absolutamente um quebra -queixo . Garantir que os rótulos sejam exclusivos agora muda para você, mas o que você recebe em troca é a importância do rótulo.

• /dev- nomeação baseada em link ao comandar um batalhão de VMs de vida relativamente baixa e baixa manutenção, que são a origem da mesma imagem, e você não apostaria em seu salário semanal que todos os UUIDs cumpram a promessa da UU. Qualquer serviço de VM sã , seja o Vyper-H em seu próprio servidor físico, na Kugel Cloud ou qualquer sdeoutra coisa, nunca chamará sua unidade de inicialização e a segunda e a única outra sdc². Em uma máquina física, por outro lado, você pode facilmente obter o mesmo arranjo conectando criativamente cabos SATA.

  Eu discordo agora, mas neste cenário, segui a mesma rota com a chamada denominação de interface Ethernet “consistente”: desabilite-a nas VMs. Não me interpretem mal, a nomeação é realmente consistente, desde que a NIC que você coloca no slot PCI 4 não salte repentinamente para o slot 5 por sua própria vontade, enquanto você não estiver olhando (ou talvez até enquanto estiver; NICs não tenha vergonha). Infelizmente, no meio do “batalhão de VMs”, eles realmente fazem. Nesse caso, contra-intuitivamente, eth0é mais consistente do queenp0s4f6. O provedor de VM não prometeu sempre colocar sua NIC virtual número 1 no slot 4 no barramento PCI 0 (e nenhuma das três entidades mencionadas é fisicamente real) e que sempre será a função 6. Mas você pode muitos dependem da primeira interface anterior à segunda, considerando que normalmente eles têm o mesmo módulo de driver, geralmente da família virtio (e se a primeira NIC nem sempre é eth0, a mesma nota² ainda se aplica).

  ---

¹ Figurativamente, é claro. Eu estive se este negócio por muito tempo para sobrar.
² Se o fizessem, eu consideraria seriamente fugir gritando deles mudando o provedor ou o software hypervisor VM.

Ambos os esquemas podem ser misturados e combinados com a maioria das distribuições linux.

As consequências podem ser desejáveis ​​ou indesejáveis, dependendo do caso de uso - por exemplo, pode-se preferir o esquema mais antigo (e até mesmo desativar os hacks de persistência no estilo udev) se a substituição a quente de (hardware virtual ou hardware real) sem precisar modificar os arquivos de configuração. procurado.

A resposta para sua segunda pergunta ("por que esse esquema de endereçamento continua sendo usado?") É, eu acho, inércia. Sim, é totalmente possível usar apenas UUIDs em discos particionados GPT. Você pode usar UUIDs em vez de /dev/xxxnomes /etc/fstab. E agora que temos a Especificação de partições detectáveis , em muitos casos, você nem precisa mais especificar os UUIDs, apenas particione seu disco com o tipo de partição e as partições serão selecionadas automaticamente. Na minha máquina, a root=entrada está totalmente ausente na linha de comando do kernel.

E por falar em gerenciadores de inicialização: o GRUB é principalmente supérfluo nos PCs UEFI modernos, no sentido de ter muito pouco a ver com a inicialização da máquina. Atualmente, o GRUB apenas funciona como um programa de seleção de kernel, para cuja tarefa existem alternativas mais simples e melhores disponíveis, como systemd-boot.