De acordo com qual algoritmo o Linux atribui as letras do disco rígido?

Question

Eu observei que entre inicializações repetidas do mesmo sistema, o mapeamento entre os nomes de dispositivos /dev/sda , /dev/sdb/ ... e os discos rígidos físicos permanece o mesmo.

No entanto, não tenho certeza se permanece o mesmo se eu conectar os discos rígidos em diferentes soquetes da placa-mãe ou se eu adicionar / remover unidades.

Quais garantias o Linux faz em relação ao mapeamento de nomes de dispositivos para os discos rígidos físicos?

Quais regras são usadas para mapear discos rígidos físicos para arquivos em / dev /?

    

Answer 1

Os nomes das unidades são (em um sistema Linux típico) decididos pelo kernel (como o dispositivo deve primeiro ser detectado lá), e podem ser modificados posteriormente pelo udev. Como decide qual hardware mapeia qual arquivo especial de bloco é um detalhe de implementação que dependerá da sua configuração do udev, configuração do kernel, configuração do módulo e muitas outras coisas também (incluindo sorte).

Normalmente, o udev atribui a primeira letra a qualquer dispositivo detectado primeiro, o que não é garantido ser sempre o mesmo, mesmo com o mesmo hardware e configuração (existem alguns sistemas particularmente propensos a trocar nomes de dispositivos devido a isso condição de corrida).

Para responder à pergunta que você não fez, não use /dev/sd* como um identificador para nada, a menos que tenha certeza sobre o dispositivo que está montando anteriormente (por exemplo, você está montando manualmente após verificar com fdisk e / ou blkid ). Em vez disso, use rótulos de sistema de arquivos, UUIDs do sistema de arquivos ou IDs de disco para garantir que você esteja apontando para o dispositivo, a partição ou o sistema de arquivos correto por suas propriedades, em vez de sua ordem de detecção. Você pode encontrar os IDs de disco em /dev/disk/by-id , que é um local conveniente para montar e garante que você esteja sempre usando o mesmo disco.

Para descobrir quais IDs de disco você pode usar para a partição atualmente em /dev/sda1 , por exemplo, você pode usar find :

$ find -L /dev/disk/by-id -samefile /dev/sda1
/dev/disk/by-id/wwn-0x5000cca22dd9fc29-part1
/dev/disk/by-id/ata-HGST_HUS724020ALA640_PN1181P6HV51ZW-part1

    

Answer 2

Eu tenho um drive USB externo, que eu monto por rótulo, então ele sempre monta quando o fstab é executado, no entanto, eu ainda tenho problemas. Às vezes, a atribuição da unidade será alterada mesmo com o dispositivo montado, e os arquivos na unidade alterada ficarão inacessíveis.

Estou executando o Ubuntu 16.04.4 LTS (Linux 4.4.0-128-genérico i686).

Eu uso o modo de suspensão entre as sessões diárias e suspeito que a unidade seja reatribuída ao acordar do modo de suspensão, embora eu não esteja absolutamente certo sobre isso. Normalmente é atribuído / dev / sdc, e eu tenho um leitor de cartão SD USB que deixo conectado, que é atribuído / dev / sdd. Há momentos em que não consigo ler ou gravar na unidade externa. Quando isso acontece, acho que foi reatribuído para / dev / sde. Uma correção é simplesmente reiniciar o sistema operacional, e tudo volta feliz, mas estou procurando uma correção onde não precise ir a esse extremo.

Eu descobri que uma correção melhor é primeiro fechar qualquer aplicativo que esteja acessando qualquer partição na unidade externa, incluindo quaisquer guias de terminal que estejam em uma pasta em uma partição na unidade externa. Se eu tenho um aplicativo onde fiz alterações em um arquivo que está na unidade inacessível, é necessário salvar o arquivo em outra partição acessível, por dois motivos: 1) para que os dados sejam salvos e 2) para quebrar o arquivo. link para a partição inacessível. Então eu desmonto a (s) partição (ões) com

sudo umount /dev/sde

ou qualquer atribuição para todas as partições da unidade externa. Então eu remontar todas as partições com

sudo mount -a

Depois de fazer isso, acho que a partição errante agora está acessível novamente por qualquer aplicativo, mesmo se a partição ainda estiver atribuída / dev / sde em vez do / dev / sdc esperado. Como fstab trabalha com rótulos e monta essas partições para pastas, essa reatribuição não é um problema. Eu pareço ter que fazer isso duas ou três vezes por mês.

Eu estou querendo saber, embora eu use rótulos para identificação de partição, se montar mapeia o rótulo para a atribuição de letra de dispositivo, que é o que está causando esse problema. Eu não posso dizer com certeza ... apenas ponderando.

    

Answer 3

Pergunta relacionada (da barra lateral automática): Como impede / sda / sdb muda entre as botas?

Garante atribuí-los na ordem em que eles são "sondados" (ou "ligados") pelo kernel.

Greg KH defende não confiar nesta ordem. Ele gosta de dar um exemplo de uma placa-mãe (real!) De design hediondo, que reorganiza a ordem PCI entre inicializações subseqüentes. Parece que a pergunta acima é sobre um exemplo.

Os módulos carregáveis são carregados pelo userspace. udev é paralelizado usando vários processos e não garante o carregamento de módulos em nenhuma ordem específica. A paralelização da inicialização como essa pode ter benefícios reais de desempenho, já que as funções de inicialização do módulo podem ser executadas em paralelo e essas funções podem incluir atrasos longos à espera de hardware.

Atualmente, é possível supor que o kernel padrão é sondar os drivers integrados de forma síncrona e, portanto, em uma ordem determinística.

As of v4.2 the Linux kernel now sports asynchronous probe support

(aparentemente esse recurso é usado pelo Google Chrome OS).

link

link

Com base em mensagens históricas , você também pode ter presumido que há ceticismo / fadiga em relação a tais esforços, não menos importante. de Linus. Com base no acima exposto, parece que qualquer escrutínio aprimorado e / ou mensagens aleatórias furiosas não impediram a fusão desta opção.

Ativá-lo em todo o kernel é outra questão, já que "[alguns] drivers não funcionam bem com sondagem assíncrona devido a erro de driver ou organização do driver não ideal". Talvez Linus não tenha explodido (?) Na mensagem de consolidação que diz "o objetivo final é tornar a sondagem assíncrona por padrão", mas isso é apenas uma opinião, e ela não nos diz quão bem ela progrediu desde v4.2.

    

Answer 4

What guarantees does Linux make regarding the mapping of device names to the physical hard drives?

Which rules does it use to map physical hard drives to files in /dev/?

Eu não posso falar por todas as distribuições do Linux, mas posso falar sobre como o SUSE faz isso, no SUSE estão disponíveis estas opções

montar por

• nome do dispositivo
• código do dispositivo
• rótulo de volume
• caminho do dispositivo
• UUID

por nome do dispositivo Eu diria que é ruim porque faz com que o linux verifique o hardware e a ordem Em que ele vê unidades conectadas é como ele faz o mapeamento para sda, sdb e assim por diante. Portanto, se o dispositivo de inicialização e a partição forem chamados como sda e você simplesmente alternar a ordem das unidades em slots removíveis (em um servidor) ou alternar os cabos sata em um computador doméstico entre duas unidades, isso irá atrapalhar as coisas. Também minha experiência tem sido (em servidores com 8, 16 ou 24 baias de unidade) que muitas vezes vai para trás que o slot 0 não mapeia para sda ... se você tivesse 3 unidades, então o slot 2 é sda, slot 1 sdb, e slot 0 sdc. E adicione qualquer hardware temporário que seja mapeado como /dev/sda e empurre as unidades para baixo em uma letra que perturba as coisas. Mas eu vou dizer que esse método é bom quando você configura uma unidade de sistema operacional de imagem de ouro que você planeja clonar ... você não precisa se preocupar com IDs de disco rígido ou WWN's mudando em um novo disco por um tempo. .. se for o disco somente no sistema, é provável que sempre apareça como sda.

FSTAB syntax:**
/dev/sdc2 / EXT3 acl,user_xattr 1 1
/dev/sdc1 /boot/efi VFAT
/dev/sdb1 /data XFS defaults 1 0

por device id é o que eu sempre uso porque resolve basicamente todos os problemas mencionados para "por nome de dispositivo", e funcionou bem para mim ao longo dos anos que quase tudo. Uma vez que a montagem é configurada pelo ID do dispositivo, as unidades precisam estar presentes ou conectadas. Se as unidades forem movidas ou o novo hardware for mapeado como /dev/sd? , isso não afetará nada que tenha sido configurado anteriormente.

FSTAB syntax:
/dev/disk/by-id/scsi-35000aab12345a30-part2 / EXT3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-35000aab12345a30-part1 /boot/efi VFAT
/dev/disk/by-id/scsi-3600404abc123def456-part1 /data XFS defaults 1 0

pelo UUID {identificador universalmente único} Acho que também é um bom, funciona muito parecido com "por device-id", mas não sei como o UUID é criado e se torna único ou se acaba sendo o mesmo que pelo id do dispositivo?

por rótulo de volume também pode funcionar bem desde que você ou alguém tenha feito um bom rótulo de volume para qualquer sistema de arquivos ou partição ou volume a ser montado. Tenho certeza que seria problemático se duas partições tivessem o mesmo rótulo de volume, como por exemplo "boot" por exemplo, suspeito qualquer volume que o lablel linux encontre primeiro é o que ele usaria se ele não relatasse duplicado rótulos de volume.

Além disso, tudo isso é baseado no linux Udev (para responder qual algoritmo é usado). Eu acredito que é o mesmo do Init linux mais antigo, assim como no mais novo linux do Systemd, já que o Udev é o pacote usado na maioria das distribuições do Linux. E eu acho que é principalmente a sintaxe em /etc/fstab especificamente o primeiro campo ou coluna em cada linha é o que determina o método de montagem que vai acontecer (não algoritmo), que não há algum outro arquivo de configuração em algum lugar e eu digo isso porque você pode ter várias linhas em /etc/fstab cada montagem algo diferente por um método de montagem diferente (por nome, id, uuid ou label) e tanto quanto eu sei mais nada em qualquer lugar mudou, exceto pela sintaxe no arquivo fstab.