O CentOS 7 não mostra as duas primeiras unidades no intel C606 SCU

Question

O CentOS 7 não mostra as duas primeiras unidades no intel C606 SCU

#1 resposta do (1 votos)

1

Estou usando uma placa-mãe SuperMicro X9SRi-3F, que usa o chipset Intel C606 e possui uma SCU dupla de 4 portas com capacidade SAS. Os HDDs que estou usando são 4x WD Re (WD6001F9YZ) e 2x WD Gold (WD6002FRYZ). Todos têm 6 TB de capacidade.

Os WD6001F9YZ estão conectados às portas 0-3, e os WD6002FRYZs estão nas portas 4 e 5 (deve-se notar, eu eventualmente adicionarei mais dois WD6001F9YZ às portas 6 e 7).

O sistema operacional é instalado em uma unidade de 1 TB conectada a uma das portas normais SATA 2.0 da placa.

O CentOS 7 pode reconhecer todas as unidades, pois lsblk gera o seguinte:

NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda               8:0    0   5.5T  0 disk 
sdb               8:16   0   5.5T  0 disk 
sdc               8:32   0   5.5T  0 disk 
sdd               8:48   0   5.5T  0 disk 
sde               8:64   0   5.5T  0 disk 
sdf               8:80   0   5.5T  0 disk

Eles também aparecem em /dev/disk/by-id :

lrwxrwxrwx. 1 root root  9 Oct 17 14:06 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA58PYRS -> ../../sda
lrwxrwxrwx. 1 root root  9 Oct 17 14:06 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LV7KR -> ../../sdb
lrwxrwxrwx. 1 root root  9 Oct 17 14:06 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LV87E -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 14:06 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVL4J -> ../../sdd
lrwxrwxrwx. 1 root root  9 Oct 17 14:06 ata-WDC_WD6002FRYZ-01WD5B0_K1HNL2KD -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 14:06 ata-WDC_WD6002FRYZ-01WD5B0_K1JMY3ND -> ../../sdf

No entanto, apenas as unidades c-f aparecem em /dev/disk/by-path :

lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-0x500304801349fe00-lun-0 -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-0x500304801349fe01-lun-0 -> ../../sdf
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-0x500304801349fe02-lun-0 -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-0x500304801349fe03-lun-0 -> ../../sdd
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-phy0-lun-0 -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-phy1-lun-0 -> ../../sdf
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-phy2-lun-0 -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 13:42 pci-0000:03:00.0-sas-phy3-lun-0 -> ../../sdd

No BIOS do MB, quando a unidade SCU está ativada e o "Driver de ROM / UEFI da opção RAID SCU" está ativado, todas as unidades são reconhecidas:

QuandoaunidadeSCUestáhabilitada,masaOptionROMestádesativada,asunidadesnãoaparecemnoBIOS:

Ambas as configurações (Option ROM Disabled / Enabled) resultam no mesmo problema. Claro, desabilitar o SCU significa que ele não aparece no sistema operacional (desaparece da saída do lspci)

A saída de lshw -c storage é assim:

*-sas                     
   description: Serial Attached SCSI controller
   product: C606 chipset Dual 4-Port SATA/SAS Storage Control Unit
   vendor: Intel Corporation
   physical id: 0
   bus info: pci@0000:03:00.0
   logical name: scsi6
   logical name: scsi7
   version: 06
   width: 64 bits
   clock: 33MHz
   capabilities: sas pm pciexpress msix bus_master cap_list
   configuration: driver=isci latency=0
   resources: irq:49 memory:fa8f8000-fa8fffff memory:fa000000-fa7fffff ioport:e100(size=256) ioport:e000(size=256) memory:fa800000-fa8f7fff

Este é um problema para mim, pois pretendo configurar um array ZFS de 8 discos e desejar referenciar a localização física da unidade no sistema (slot1, slot2, etc).

Minha intuição me diz que é um problema com o driver do kernel para o C606, mas honestamente não faço ideia.

[EDITAR]

Se eu usar hotplug nas outras unidades SATA que pretendo usar nas portas 6 e 7, /dev/disk/by-path ficará assim:

lrwxrwxrwx. 1 root root  9 Oct 17 14:20 pci-0000:03:00.0-sas-0x5fcfffff00000001-lun-0 -> ../../sda
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 pci-0000:03:00.0-sas-0x5fcfffff00000002-lun-0 -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 pci-0000:03:00.0-sas-0x5fcfffff00000003-lun-0 -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 14:24 pci-0000:03:00.0-sas-0x5fcfffff00000004-lun-0 -> ../../sdi
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-0x5fcfffff00000004-lun-0-part1 -> ../../sdi1
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-0x5fcfffff00000004-lun-0-part2 -> ../../sdi2
lrwxrwxrwx. 1 root root  9 Oct 17 14:24 pci-0000:03:00.0-sas-0x5fcfffff00000005-lun-0 -> ../../sdj
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-0x5fcfffff00000005-lun-0-part1 -> ../../sdj1
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-0x5fcfffff00000005-lun-0-part2 -> ../../sdj2
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 pci-0000:03:00.0-sas-phy0-lun-0 -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 pci-0000:03:00.0-sas-phy1-lun-0 -> ../../sdb
lrwxrwxrwx. 1 root root  9 Oct 17 14:24 pci-0000:03:00.0-sas-phy2-lun-0 -> ../../sdi
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-phy2-lun-0-part1 -> ../../sdi1
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-phy2-lun-0-part2 -> ../../sdi2
lrwxrwxrwx. 1 root root  9 Oct 17 14:24 pci-0000:03:00.0-sas-phy3-lun-0 -> ../../sdj
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-phy3-lun-0-part1 -> ../../sdj1
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 pci-0000:03:00.0-sas-phy3-lun-0-part2 -> ../../sdj2

A parte do caminho que começou anteriormente com sas-0x500304801349fe## foi alterada para sas-0x5fcfffff000000## porque desativei a opção ROM no BIOS. Mas o que é interessante aqui é que sdd e sdf desapareceram do diretório by-path , mas sda , sdi e sdj apareceram. Além disso, o pedido foi alterado.

É claro que todas as oito unidades aparecem no diretório by-id :

lrwxrwxrwx. 1 root root  9 Oct 17 14:20 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA58PYRS -> ../../sda
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LV7KR -> ../../sdb
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LV87E -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 14:24 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVJK2 -> ../../sdj
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVJK2-part1 -> ../../sdj1
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVJK2-part2 -> ../../sdj2
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVL4J -> ../../sdd
lrwxrwxrwx. 1 root root  9 Oct 17 14:24 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVNXX -> ../../sdi
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVNXX-part1 -> ../../sdi1
lrwxrwxrwx. 1 root root 10 Oct 17 14:24 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVNXX-part2 -> ../../sdi2
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 ata-WDC_WD6002FRYZ-01WD5B0_K1HNL2KD -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 14:20 ata-WDC_WD6002FRYZ-01WD5B0_K1JMY3ND -> ../../sdf

[EDIT 2]

O diretório by-path parece mudar a cada inicialização agora. Atualmente, é assim:

lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-0x5fcfffff00000001-lun-0 -> ../../sda
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-0x5fcfffff00000002-lun-0 -> ../../sdb
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-0x5fcfffff00000003-lun-0 -> ../../sdf
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-0x5fcfffff00000004-lun-0 -> ../../sdd
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-phy0-lun-0 -> ../../sda
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-phy1-lun-0 -> ../../sdf
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-phy2-lun-0 -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 pci-0000:03:00.0-sas-phy3-lun-0 -> ../../sdd

Enquanto o caminho by-id se parece com isto:

lrwxrwxrwx. 1 root root  9 Oct 17 15:03 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA58PYRS -> ../../sda
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LV7KR -> ../../sdb
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LV87E -> ../../sdc
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 ata-WDC_WD6001F9YZ-09YUWL1_WD-WX41DA5LVL4J -> ../../sdd
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 ata-WDC_WD6002FRYZ-01WD5B0_K1HNL2KD -> ../../sde
lrwxrwxrwx. 1 root root  9 Oct 17 15:03 ata-WDC_WD6002FRYZ-01WD5B0_K1JMY3ND -> ../../sdf

Os discos são consistentemente atribuídos ao mesmo ID de dispositivo (sda / sdb / etc), o que é reconfortante, mas o caminho muda de forma imprevisível (tornando-o completamente inutilizável para os meus propósitos).

[EDIT 3]

A saída de du -a /sys/devices/pci0000\:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0 | grep -E 'sd.' | grep -vE 'sd./' mostra o mapeamento correto para as unidades:

0   /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host6/port-6:0/end_device-6:0/target6:0:0/6:0:0:0/block/sda
0   /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host6/port-6:1/end_device-6:1/target6:0:1/6:0:1:0/block/sdb
0   /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host6/port-6:2/end_device-6:2/target6:0:2/6:0:2:0/block/sdc
0   /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host6/port-6:3/end_device-6:3/target6:0:3/6:0:3:0/block/sdd
0   /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host7/port-7:0/end_device-7:0/target7:0:0/7:0:0:0/block/sde
0   /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host7/port-7:1/end_device-7:1/target7:0:1/7:0:1:0/block/sdf

Então, acho que esse problema está relacionado a um bug em udev

intel storage centos hard-disk

por Toasty 17.10.2017 / 23:31

1 resposta

Tags intel storage centos hard-disk

ssh tunnel não funciona O udev carrega módulos do kernel?

score 1 · Answer 1

Eu também tenho um servidor Dell T420, e a saída de udevadm info me dá isso:

E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:0/0:0:0:0/block/sda
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:1/0:0:1:0/block/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:2/0:0:2:0/block/sdc
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:3/0:0:3:0/block/sdd
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:4/0:0:4:0/block/sde
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:5/0:0:5:0/block/sdf
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:6/0:0:6:0/block/sdg
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:08:00.0/host0/target0:0:7/0:0:7:0/block/sdh

Como você pode ver, há apenas no caso de host# no caminho do dispositivo ( host0 ), enquanto o SCU da Intel tem dois ( host6 e host7 ). Aparentemente o udev no CentOS 7 não sabe como lidar com isso corretamente, e simplesmente sobrescreve os links do dispositivo (então qualquer dispositivo sob o nó host6 obtém seu link simbólico em /dev/disks/by-path sobrescrito pelo dispositivo correspondente sob o nó host7 ) .

Parece que eu preciso aprender a escrever regras do udev agora ...

[EDITAR]

Tentativa inicial de uma regra do udev para resolver o problema: link

É muito feio e cheio de bugs. Não manipula o hot plug corretamente, e não faz nada com partições. Eu preciso encontrar uma maneira de criar as propriedades atualizadas a partir de informações existentes, em vez de editá-las no local, caso contrário, há uma chance de os caminhos mudarem sempre que as regras do udev forem recarregadas.

[EDIT 2]

O Gist foi atualizado para gerar caminhos semelhantes aos produzidos pela função handle_scsi_default no path_id builtin. É muito mais confiável agora e também lida com partições. Espero que alguém também ache útil. Ainda é um truque, então YMMV.

Atualmente trabalhando para obter uma correção adequada corrigida no udev.