All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Alibek Amaev <alibek.a@gmail.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: Block device naming
Date: Thu, 16 May 2019 16:07:43 +0200	[thread overview]
Message-ID: <680c9440-f1c9-68d1-cc5a-17aa9071fcc1@suse.de> (raw)
In-Reply-To: <CA+TYKz1E3mJ0hDQcv19QAFgeWVA-ADLoHtGQ5hy8SFxHOfuqfQ@mail.gmail.com>

On 5/16/19 3:49 PM, Alibek Amaev wrote:
> I have more example from IRL:
> In Aug 2018 I was start server with attached storages by FC from ZS3
> and ZS5 (it is Oracle ZFS Storage Appliance, not NetApp and also
> export space as LUN) server use one LUN from ZS5. And recently on
> server stopped all IO on this exported LUN  and io-wait is grow, in
> dmesg no any errors or any changes about FC, no errors in
> /var/log/kern.log* /var/log/syslog.log*, no throttling, no edac errors
> or other.
> But before reboot I saw:
> wwn-0x600144f0b49c14d100005b7af8ee001c -> ../../sdc
> I try to run partprobe or try to copy from this block device some data
> to /dev/null by dd - operations wasn't finished IO is blocked
> And after reboot i seen:
> wwn-0x600144f0b49c14d100005b7af8ee001c -> ../../sdd
> And server is run ok.
> 
> Also I have LUN exported from storage in shared mode and it accesible
> for all servers by FC. Currently this LUN not need, but now I doubt it
> is possible to safely remove it...
> 
It's all a bit conjecture at this point.
'sdc' could be show up as 'sdd' after the next reboot, with no 
side-effects whatsoever.
At the same time, 'sdc' could have been blocked by a host of reasons, 
none of which are related to the additional device being exported.

It doesn't really look like an issue with device naming; you would need 
to do proper investigation on your server to figure out why I/O stopped.
Device renaming is typically the least likely cause here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

  reply	other threads:[~2019-05-16 14:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 12:26 Block device naming Alibek Amaev
2019-05-16 12:33 ` Hannes Reinecke
2019-05-16 13:49   ` Alibek Amaev
2019-05-16 14:07     ` Hannes Reinecke [this message]
2019-05-17 11:24       ` Alibek Amaev
  -- strict thread matches above, loose matches on Subject: below --
2019-05-09 20:43 Alibek A.
2019-05-15 11:46 ` Alibek Amaev

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=680c9440-f1c9-68d1-cc5a-17aa9071fcc1@suse.de \
    --to=hare@suse.de \
    --cc=alibek.a@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.