LINUX.ORG.RU
Форум — Admin  

По номеру контроллера узнать серийник диска?


1

1

Есть сервер (самосбор) с 8 дисками. 6 подключены в контроллер на материнской плате, 2 - на внешний PCI-E контроллер.


Начались затейливые косяки с файлухой

Куски dmesg:


ata7.00: exception Emask 0x10 SAct 0x1 SErr 0x780100 action 0x6
ata7.00: irq_stat 0x08000000
ata7: SError: { UnrecovData 10B8B Dispar BadCRC Handshk }
ata7.00: failed command: READ FPDMA QUEUED
ata7.00: cmd 60/80:00:06:dd:3c/00:00:00:00:00/40 tag 0 ncq 65536 in
res 40/00:00:06:dd:3c/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
ata7.00: status: { DRDY }
ata7: hard resetting link
ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata7.00: configured for UDMA/133
ata7: EH complete
udev: starting version 146
<3>udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly
ata7.00: exception Emask 0x10 SAct 0x2 SErr 0x780100 action 0x6
ata7.00: irq_stat 0x08000000
ata7: SError: { UnrecovData 10B8B Dispar BadCRC Handshk }
ata7.00: failed command: READ FPDMA QUEUED
ata7.00: cmd 60/80:08:06:df:3c/00:00:00:00:00/40 tag 1 ncq 65536 in
res 40/00:08:06:df:3c/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
ata7.00: status: { DRDY }
ata7: hard resetting link
ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata7.00: configured for UDMA/133
ata7: EH complete




потом, через какое-то время



REISERFS error (device dm-3): vs-4080 _reiserfs_free_block: block 494542758: bit already cleared
REISERFS (device dm-3): Remounting filesystem read-only
------------[ cut here ]------------
WARNING: at fs/reiserfs/journal.c:3436 journal_end+0x119/0x130()
Hardware name: P5Q DELUXE
Modules linked in: xt_tcpudp iptable_filter ipt_addrtype xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_multiport xt_MARK xt_mark xt_iprange xt_hashlimit xt_conntrack xt_CONNMARK xt_connmark nf_conntrack ip_tables x_tables xfs exportfs i2c_i801 i2c_core
Pid: 10492, comm: afpd Not tainted 2.6.34-gentoo #1
Call Trace:
[<ffffffff81138629>] ? journal_end+0x119/0x130
[<ffffffff8103a508>] warn_slowpath_common+0x78/0xd0
[<ffffffff8103a56f>] warn_slowpath_null+0xf/0x20
[<ffffffff81138629>] journal_end+0x119/0x130
[<ffffffff81122959>] reiserfs_delete_inode+0xe9/0x110
[<ffffffff810d0e01>] generic_delete_inode+0x81/0x130
[<ffffffff810d0f0d>] generic_drop_inode+0x5d/0x80
[<ffffffff810cfc6d>] iput+0x5d/0x70
[<ffffffff810cc988>] dentry_iput+0x78/0xe0
[<ffffffff810ccafb>] d_kill+0x4b/0x80
[<ffffffff810cd541>] dput+0xa1/0x180
[<ffffffff810bc5c4>] __fput+0x174/0x200
[<ffffffff810bc66d>] fput+0x1d/0x30
[<ffffffff810b8e18>] filp_close+0x58/0x90
[<ffffffff810b8efd>] sys_close+0xad/0x100
[<ffffffff8100246b>] system_call_fastpath+0x16/0x1b
---[ end trace a30e273768a512a7 ]---




Я так понимаю, что из-за проблем с доступом к одному из хардов валится reiserfs? Или это не связанные проблемы?

И как узнать серийник диска (или sd?-имя), подключенный к ata7? Простое перечисление типа sda - ata0 (ata1?) не помогло. Тестирую сейчас все диски, но каждый около 5 часов прогоняет, а работа стоит.

★★★★★

Ответ на: комментарий от GotF

# ls -l /dev/disk/by-path/ ls: невозможно получить доступ к /dev/disk/by-path/: Нет такого файла или каталога

А те что есть (by-id и by-uuid) - не то.

В /sys тоже копался, не нашел, но там можно долго копаться...

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от AngryElf

Попробуй 

cat /sys/block/sda/dev

и

ls /sys/block/sda/device/

(у меня там есть каталоги с именами, соответствующими шине)

Это всё в ядре 2.6.26.

GotF ★★★★★
()
Ответ на: комментарий от GotF 
┌┤~├──────────────────────────────────────────────────────────────────────────────────┤gotf@persephone├─
└─> ls /sys/block/sda/device/
block:sda    device_blocked    iodone_cnt     model        rescan               scsi_level  type
bsg:0:0:0:0  driver            ioerr_cnt      power        rev                  state       uevent
bus          evt_media_change  iorequest_cnt  queue_depth  scsi_device:0:0:0:0  subsystem   vendor
delete       iocounterbits     modalias       queue_type   scsi_disk:0:0:0:0    timeout
┌┤~├──────────────────────────────────────────────────────────────────────────────────┤gotf@persephone├─
└─> ls /sys/block/sdb/device/
block:sdb    device_blocked    iodone_cnt     model        rescan               scsi_level  type
bsg:2:0:0:0  driver            ioerr_cnt      power        rev                  state       uevent
bus          evt_media_change  iorequest_cnt  queue_depth  scsi_device:2:0:0:0  subsystem   vendor
delete       iocounterbits     modalias       queue_type   scsi_disk:2:0:0:0    timeout
┌┤~├──────────────────────────────────────────────────────────────────────────────────┤gotf@persephone├─
└─> cat /sys/block/sda/dev
8:0
┌┤~├──────────────────────────────────────────────────────────────────────────────────┤gotf@persephone├─
└─> cat /sys/block/sdb/dev
8:16
GotF ★★★★★
()
Ответ на: комментарий от AngryElf

Т.е. bsg:0:0:0:0 === ata0?

У меня так.

я прогнал его badblocks'ом, все чисто...

Ну, S.M.A.R.T. ещё можно снять, да и сбой ФС без железных причин исключать не стоит.

GotF ★★★★★
()
Ответ на: комментарий от GotF

> да и сбой ФС без железных причин исключать не стоит.

Страшный сон... )

Хотя reiserfs на разделе в 3TB я еще не юзал.

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от AngryElf

Страшный сон... )

Страшный сон будет, когда бекапов не окажется.

Может быть проблемы и не связаны, но с железом точно не все в порядке.

zgen ★★★★★
()

Про reiserfs не в курсе, а по поводу «hard resetting link» имею сказать следующее:

Либо у тебя проблемы с кабелем к диску (маловероятно), либо не тянет блок питания. Смотри напряжения (особенно 3.3) в lm-sensors. Впрочем, около года назад в ядре был похожий баг, но его вроде давно пофиксили.

router ★★★★★
()
Ответ на: комментарий от router

смотри куда ведут симлинки. А дальше сверяешь, например, с dmesg или из /sys или /proc, там много всего.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Если б там был серийник, проблемы бы не было. Но в dmesg есть только модель, размер и версия прошивки

router ★★★★★
()
Ответ на: комментарий от router

вот смотри:

[    2.511767] scsi 0:0:0:0: Direct-Access     ATA      HITACHI HTS54321 FB2Z PQ: 0 ANSI: 5
[    2.511966] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    2.512362] sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)

HTS54321 это и есть то что написано у винта на крышке.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

:D Это и есть модель, а не серийник. Как доказательство посмотри smartctl -a sda или гугл

И ещё в этом куске лога нет упоминания об ata[0-9]. Узнать серийник sd[a-z][0-9] не проблема, а вот как узнать серийник ata[0-9] или соответствующее устройство sd[a-z][0-9] ?

router ★★★★★
() 
hdparm -I /dev/sdX | less
Deleted
()
Ответ на: комментарий от router

ну, ок, вот так показывает: 

$ dmesg | grep FB2ZC4EC
[    2.489131] ata1.00: ATA-8: HITACHI HTS543216L9SA00, FB2ZC4EC, max UDMA/100

Еслиб я не знал что это серийник я бы не говорил, много винтов так поменяли на серваках.

а вот как узнать серийник ata[0-9] или соответствующее устройство sd[a-z][0-9]

Или как выше mironov_ivan написал или внимательно посмотреть dmesg, там, на самом деле, понятно что есть что.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Возможно, это зависит от дистра или от версии ядра. У меня серийники дисков в dmesg не встречаются. Для примера взял seagate:

jb:~# smartctl -a /dev/sdb | grep -i serial
Serial Number: 9QJ2WAYT
jb:~# grep -i 9QJ2WAYT /var/log/dmesg
jb:~# dmesg | grep -i 9QJ2WAYT
jb:~#

Или как выше mironov_ivan написал или внимательно посмотреть dmesg, там, на самом деле, понятно что есть что.


hdparm не даёт информацию об ata#. И в dmesg уже второй день ищу.

Как определить серийник по имени sd* или scsi-адресу я знаю. А вот libata - тёмный лес. Если знаешь способ определить в debian, к какому диску относится ata2, например, то объясни идиоту :)

router ★★★★★
()
Ответ на: комментарий от router

так, суть проблемы понял. Мои винты(как и твои wd) прямо в dmesg суфиксом после названия модели серийник добавляют.

Короче, это /dev/sdb потому что только у него такое кол-во секторов. Это видно из dmesg.

А можешь показать ошибки от винтов из логов? Они там только ata2 пишут? По идее, там должны быть ошибки уровня scsi и найти нужный винт через какой-нить /sys/bus/scsi/devices/ не проблема.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

>Мои винты(как и твои wd) прямо в dmesg суфиксом после названия модели серийник добавляют.

Мои WD, как и seagate, не добавляют серийник в лог, что логично.

Короче, это /dev/sdb потому что только у него такое кол-во секторов. Это видно из dmesg.


У меня 2 одинаковых seagate с таким количеством секторов ;) Так что гадание на секторах не катит. И ещё 3 одинаковых WD.

А можешь показать ошибки от винтов из логов? Они там только ata2 пишут?


Ошибки были у автора топика, у меня их нет, просто захотелось тоже разобраться.

router ★★★★★
()
Ответ на: комментарий от router

ясно :). Он просто лог не целиком привёл, там дальше будет написано имя устройства. Как это выглядит можно посмотреть, например, сдесь: https://bugs.launchpad.net/ubuntu/+bug/550559


не добавляют серийник в лог


Да, точно, это номер серии. Значит мне винты из разных партий попадались, я всегда на эти циферки смотрел и они всегда позволяли в системе однозначно определить выпавший винт.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Пересмотрел ещё раз диски.

В данный момент # ata равен scsi host +1, т.е.

[0:0:0:0] ata1
[1:0:0:0] ata2
[3:0:0:0] ata4
[4:0:0:0] ata5
[5:0:0:0] ata6
[6:0:0:0] ata7 (DVD_RW)

Что характерно, при отсутствии [2:0:0:0] ata3 нет, причём с момента загрузки. Для чистоты эксперимента можно выдернуть пару винтов из разных массивов и вернуть первым тот, у которого scsi host был больше, но по-моему и так ясно :)

Тогда отсылка к bsg понятна. Единственное, я не согласен с

Т.е. bsg:0:0:0:0 === ata0?

т.к. у меня получается, что bsg:0:0:0:0 это ata1

AngryElf, GotF вы можете это прокоментировать?

router ★★★★★
()
Ответ на: комментарий от router

т.к. у меня получается, что bsg:0:0:0:0 это ata1

Да, у меня так же. Немного невнимательно смотрел — ata0 нет в принципе.

[    2.261867] scsi0 : ahci
[    2.261867] scsi1 : ahci
[    2.261867] scsi2 : ahci
[    2.261867] scsi3 : ahci
[    2.261867] ata1: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f100 irq
 22
[    2.261867] ata2: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f180 irq
 22
[    2.261867] ata3: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f200 irq 22
[    2.262403] ata4: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f280 irq 22
[    2.747214] ata1: softreset failed (device not ready)
[    2.747581] ata1: failed due to HW bug, retry pmp=0
[    2.911221] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    2.911202] ata1.00: ATA-8: ST3500418AS, CC38, max UDMA/133
[    3.052481] ata1.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 31/32)
[    3.064697] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.078379] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[    3.091209] ata1.00: configured for UDMA/133
[    3.447300] ata2: SATA link down (SStatus 0 SControl 300)
[    3.958550] ata3: softreset failed (device not ready)
[    3.971309] ata3: failed due to HW bug, retry pmp=0
[    4.215057] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    4.230434] ata3.00: ATA-8: ST3320418AS, CC35, max UDMA/133
[    4.244577] ata3.00: 625142448 sectors, multi 1: LBA48 NCQ (depth 31/32)
[    4.268562] ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
[    4.287159] ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
[    4.302008] ata3.00: configured for UDMA/133
[    4.661822] ata4: SATA link down (SStatus 0 SControl 300)

Не по теме: тут вот такая фигня интересная имеется. Видно, что на ata2 (acsi1) пусто — этот диск действительно отсоединён, и разъём идёт вторым на плате, но в BIOS он третий (когда подсоединён) %) Получается, что Linux считает разъёмы в «физическом» порядке, тогда как в BIOS соответствие разъёмов номерам выглядит как 1,3,2,4.

GotF ★★★★★
()
Ответ на: комментарий от GotF

Тогда получается, что ответ на вопрос топика примерно такой:

$ ata=ata7
$ sudo smartctl -a /dev/$(ls /sys/bus/scsi/devices/$((${ata##ata}-1))\:0\:0\:0/block) | grep -i serial | awk '{ print $3; }'
router ★★★★★
()
Ответ на: комментарий от router

> AngryElf, GotF вы можете это прокоментировать?

А хз, мне осталось дотестить еще пару хардов, пока ни одного бэда, а файлуха все так же отваливается иногда... Мистика.

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от AngryElf

Говорят же тебе, смотри в сторону питания. Скорее всего, умирает БП, проверь напряжения в lm-sensors

Если отваливается один и тот же винт, возможен вариант с плохим кабелем к диску

router ★★★★★
()
Ответ на: комментарий от router

В данный момент # ata равен scsi host +1

не стоит на это расчитывать, вдруг в системе уже есть scsi, тогда нумерация может слететь. Да и незачем, в логах отражается какой диск сбоит.

true_admin ★★★★★
()
Ответ на: комментарий от router

проверь напряжения в lm-sensors

лучше мультиметром. У меня очень чудные значения некоторые мамки показывают.

true_admin ★★★★★
()
Ответ на: комментарий от router

Вот сдесь нашёл солюшн: http://www.pubbs.net/201001/centos/69607-centos-how-to-map-ata-numbers-to-devsd-numbers.html:

for d in $(ls -d /sys/class/scsi_host/host?); do echo "$d $(cat $d/proc_name) $(cat $d/unique_id)" ; done

По поводу того будут ли номера всегда отличаться на единицу так из сырцов сходу непонятно.

true_admin ★★★★★
()
Ответ на: комментарий от router

> Говорят же тебе, смотри в сторону питания. Скорее всего, умирает БП, проверь напряжения в lm-sensors

Оно б тогда глючило бессистемно и на разных хардах.

Если отваливается один и тот же винт, возможен вариант с плохим кабелем к диску

Проверяли, вроде. Проверим еще раз.

AngryElf ★★★★★
() автор топика
Ответ на: комментарий от AngryElf

Поменял хард, проблемы (по крайней мере пока), исчезли. Посмотрим.

AngryElf ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin