From: Brandon R Schwartz <brandon.r.schwartz@seagate.com>
To: linux-hotplug@vger.kernel.org
Subject: Improper Naming in /dev/disk/by-id and Drives Offline
Date: Thu, 11 Sep 2014 02:34:06 +0000 [thread overview]
Message-ID: <CAFg=k-gDSYG8L68hVky1-j_1xExhzMcX6gobf0a35OtRhdbKVg@mail.gmail.com> (raw)
Hi,
I'm working on a particular issue (possibly two separate issues) where
our HDDs are (1) getting mislabeled in /dev/disk/by-id and (2)
dropping offline even though drive and controller logs show that the
drive is communicating and working as expected. I don't have much
knowledge on the udev side of things so it would be great if someone
could offer some insight into the way udev assigns device names and if
there are thoughts as to why the OS cannot see the drive in certain
cases (timing issue?).
The first issue, the mislabeling problem, is that on reboots or power
cycles we occasionally see our drives become mislabeled in
/dev/disk/by-id. We expect to see something like:
ata-ST3000DM001-1CH166_W1F26HKK
ata-ST3000DM001-1CH166_Z1F2FBBY
But instead we see:
ata-ST3000DM001-1CH166_W1F26HKK
scsi-35000c500668a9bdb
The "scsi" drive is assigned a drive letter and the OS can communicate
with the drive. Drives logs and controller logs show the drive is
working properly, but for some reason it's getting labeled incorrectly
in /dev/disk/by-id. We have looked through dmesg and enabled logging
in udev (udevadm control --log-priorityfibug), but we have not seen
where these labels are coming from.
The second issue is slightly related to the first in that it appears
during the same power cycle/reboot test. We have noticed that on
occasion, our drives will not be detected by the OS (not listed in
/dev/disk/by-id) at all. However, if we look at drive logs and
controller logs, we don't see any issue. The controller is able to
see the drives and communicate with them, but the OS is unable to.
Any ideas as to why communication is not established?
Also, is there a way to refresh the /dev/disk/by-id listing (udevadm
trigger?) once the OS has booted in order to rescan for attached
devices and repopulate it? Thanks for any information and let me know
if you need logs or anything else.
Regards,
Brandon
--
Brandon Schwartz
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2014-09-11 2:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 2:34 Brandon R Schwartz [this message]
2014-09-11 2:53 ` Improper Naming in /dev/disk/by-id and Drives Offline Greg KH
2014-09-12 17:52 ` Brandon R Schwartz
2014-09-12 18:03 ` Greg KH
2014-09-12 18:53 ` Brandon R Schwartz
2014-09-12 22:42 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFg=k-gDSYG8L68hVky1-j_1xExhzMcX6gobf0a35OtRhdbKVg@mail.gmail.com' \
--to=brandon.r.schwartz@seagate.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).