Eu acordei esta manhã com um e-mail de notificação com algumas entradas de log do sistema bastante preocupantes.
Dec 2 04:27:01 yeono kernel: [459438.816058] ata2.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen
Dec 2 04:27:01 yeono kernel: [459438.816071] ata2.00: failed command: WRITE FPDMA QUEUED
Dec 2 04:27:01 yeono kernel: [459438.816085] ata2.00: cmd 61/08:00:70:0d:ca/00:00:08:00:00/40 tag 0 ncq 4096 out
Dec 2 04:27:01 yeono kernel: [459438.816088] res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout)
Dec 2 04:27:01 yeono kernel: [459438.816095] ata2.00: status: { DRDY }
(the above five lines were repeated a few times at a short interval)
Dec 2 04:27:01 yeono kernel: [459438.816181] ata2: hard resetting link
Dec 2 04:27:02 yeono kernel: [459439.920055] ata2: SATA link down (SStatus 0 SControl 300)
Dec 2 04:27:02 yeono kernel: [459439.932977] ata2: hard resetting link
Dec 2 04:27:09 yeono kernel: [459446.100050] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Dec 2 04:27:09 yeono kernel: [459446.314509] ata2.00: configured for UDMA/133
Dec 2 04:27:09 yeono kernel: [459446.328037] ata2.00: device reported invalid CHS sector 0
("reported invalid CHS sector 0" repeated a few times at a short interval)
Eu faço backups noturnos completos de todo o meu sistema em uma unidade externa (conectada por USB), e o que aconteceu acima ocorreu no meio dessa execução de backup. (O backup começa às 04:00 até o cron e a conclusão registrada desta noite é anterior às 04:56.) O próprio processo de backup afirma ter sido concluído sem erros.
Existem duas unidades SATA conectadas internamente e duas unidades conectadas externamente (USB) no meu sistema; uma das unidades externas está inativa no momento. Não me lembro do topo da minha cabeça quais portas SATA físicas são usadas para quais das unidades internas.
Quando googling eu encontrei a pergunta AskUbuntu Esta falha de unidade ou algo mais? que indica que um erro muito semelhante ocorreu depois de 8-10 GB terem sido copiados para uma unidade, mas o modo de falha real foi diferente quando a unidade mudou para um estado somente leitura. A única semelhança real é que eu adicionei na ordem de 7-8 GB de dados para o meu armazenamento principal na noite passada, o que teria sido feito backup em torno do tempo que o erro ocorreu.
smartd não está relatando nada fora do comum em nenhuma das unidades internas. Infelizmente, o smartctl não fala o idioma da ponte USB da unidade de backup externa e simplesmente reclama sobre Unknown USB bridge [0x0bc2:0x3320 (0x100)] . Pesquisando por esse erro específico foi claramente inútil.
Meu armazenamento de dados principal, bem como o backup, está no ZFS e zpool status reports 0 erros e nenhum erro de dados conhecido. No entanto, iniciei uma limpeza completa nas unidades internas e externas. Está programado para ser concluído em aproximadamente seis horas para a unidade interna (pool de armazenamento principal) e 13 a 14 horas para a unidade de backup.
Parece que o próximo passo deve ser determinar qual disco estava tendo problemas e possivelmente substituí-lo. A ata2.00 parte provavelmente informa qual unidade estava tendo problemas, mas como mapear esse identificador para uma unidade física?
Eu escrevi uma linha baseada em Tobi Hahn answer .
Por exemplo, você quer saber qual dispositivo representa ata3:
ata=3; ls -l /sys/block/sd* | grep $(grep $ata /sys/class/scsi_host/host*/unique_id | awk -F'/' '{print $5}')
Produzirá algo assim
lrwxrwxrwx 1 root root 0 Jan 15 15:30 /sys/block/sde -> ../devices/pci0000:00/0000:00:1f.5/host2/target2:0:0/2:0:0:0/block/sde
Use este comando:
ls -l /sys/block/sd* | sed 's/.*\(sd.*\) -.*\(ata.*\)\/h.*/ => /'
No meu sistema, isso produz a saída:
ata1 => sda
ata2 => sdb
ata3 => sdc
ata4 => sdd
ata7 => sde
ata8 => sdf
Isso funcionará mesmo se todos os discos tiverem o mesmo modelo de unidade (entre esses 6 discos existem apenas dois modelos diferentes). Note que isso depende da nomeação do sysfs e funciona no meu kernel 3.10.17. Eu sei que em algum momento no passado não foi tão limpo recuperar os mapeamentos, mas não tenho certeza de qual será a versão mais antiga do kernel para isso.
Se não funcionar para você, veja este link para uma maneira mais indireta de determinar os mapeamentos: link
Acontece que fazer o mapeamento foi mais fácil do que eu percebi.
dmesg | grep ata2 | head fornece o mapeamento do kernel da unidade durante o processo de inicialização. Ou você poderia simplesmente ir para ata2.00 imediatamente.
[ 2.448300] ata2: SATA max UDMA/133 abar m1024@0xfeb0b000 port 0xfeb0b180 irq 19
[ 2.940139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2.942143] ata2.00: ATA-8: ST31000340NS, SN05, max UDMA/133
[ 2.942149] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 2.944573] ata2.00: configured for UDMA/133
(and some stuff I'd rather never have to see about drive errors)
Como você pode ver, uma dessas linhas contém o número do meu modelo de unidade ( ST31000340NS ), que eu posso usar para mapear para um arquivo /dev :
$ readlink /dev/disk/by-id/*ST31000340NS* | head -n1
../../sda
Aqui está um onliner para descobrir todos os sd* devices:
LC_ALL=C ls -l /sys/block/sd* | perl -npe 's#^.*?block/(sd[^/ ]+).*?/pci0000:00/0000:([^/]+/(?:ata[0-9]+|usb[0-9]+/[^/]+/[^/]+|[0-9:.]+/[^/]+/[^/]+)).*#$1 = $2#'
Para mim, a saída parece
sda = 00:01.0/0000:01:00.0/host0/port-0:0
sdb = 00:01.0/0000:01:00.0/host0/port-0:1
sdc = 00:01.0/0000:01:00.0/host0/port-0:2
sdd = 00:01.0/0000:01:00.0/host0/port-0:3
sde = 00:1d.0/usb2/2-1/2-1.5
sdf = 00:1f.2/ata3
sdg = 00:1f.2/ata4
sdh = 00:1f.2/ata6
A saída deve ser bastante legível e os dispositivos PCI Express e os dispositivos USB também obtêm algo sensato. Você pode então usar o início do dispositivo para descobrir a conexão real do hardware. Por exemplo, no exemplo acima, 01:00.0 é a placa Intel SSD 910 PCI Express com quatro sub-dispositivos SSD de 200GB. A saída lspci -nn | grep -F 01:00.0 para o mesmo hardware é
01:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03)
Portanto, o kernel acha que sda ... sdd está conectado ao controlador LSI Logic PCI-Express SAS-2. Infelizmente, parece não haver nenhuma maneira fácil de "saber" que esse dispositivo é realmente a placa Intel SSD 910 PCI Express.