Linux-NVME Archive on lore.kernel.org
 help / color / Atom feed
* "nvme disconnect" for mounted volumes - stuck thread
@ 2019-09-09 10:06 Szymon Scharmach
  2019-09-09 19:31 ` Sagi Grimberg
  0 siblings, 1 reply; 2+ messages in thread
From: Szymon Scharmach @ 2019-09-09 10:06 UTC (permalink / raw)
  To: linux-nvme

Hi,

In the deployment scenario i am using we use around 200 NvmeOF volumes
that are being connected to different initiators and after data have
been saved - reconnected to different ones.
nvme cli allows to disconnect volumes that are either mounted or
umount is in progress which leads threads to end up in uninterruptible
sleep. (D state)

root      69368  0.0  0.0   6704   640 ?        D    09:29   0:00 nvme
disconnect --nqn=pvc-4f6b7502-cb08-11e9-a2bf-3cfdfeb878d0
root      69375  0.0  0.0   5920   900 ?        D    09:29   0:00
umount /var/lib/origin/openshift.local.volumes/pods/4f6caee2-cb08-11e9-a2bf-3cfdfe-b878d0/
volumes/kubernetes.io~csi/pvc-4f6b7502-cb08-11e9-a2bf-3c

Those threads are stuck in D forever and whole block stack on the node
becomes unusable.
Is it the responsibility of nvme-cli or kernel module (nvme_fabrics
AFAIK) to block 'disconnect' in that case - or is it expected behavior
(nvme disconnect with force flag maybe) ?


BR\
Szymon Scharmach

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: "nvme disconnect" for mounted volumes - stuck thread
  2019-09-09 10:06 "nvme disconnect" for mounted volumes - stuck thread Szymon Scharmach
@ 2019-09-09 19:31 ` Sagi Grimberg
  0 siblings, 0 replies; 2+ messages in thread
From: Sagi Grimberg @ 2019-09-09 19:31 UTC (permalink / raw)
  To: Szymon Scharmach, linux-nvme


> Hi,
> 
> In the deployment scenario i am using we use around 200 NvmeOF volumes
> that are being connected to different initiators and after data have
> been saved - reconnected to different ones.
> nvme cli allows to disconnect volumes that are either mounted or
> umount is in progress which leads threads to end up in uninterruptible
> sleep. (D state)
> 
> root      69368  0.0  0.0   6704   640 ?        D    09:29   0:00 nvme
> disconnect --nqn=pvc-4f6b7502-cb08-11e9-a2bf-3cfdfeb878d0
> root      69375  0.0  0.0   5920   900 ?        D    09:29   0:00
> umount /var/lib/origin/openshift.local.volumes/pods/4f6caee2-cb08-11e9-a2bf-3cfdfe-b878d0/
> volumes/kubernetes.io~csi/pvc-4f6b7502-cb08-11e9-a2bf-3c

Do you have the watchdog hand detector trace to share?

> 
> Those threads are stuck in D forever and whole block stack on the node
> becomes unusable.
> Is it the responsibility of nvme-cli or kernel module (nvme_fabrics
> AFAIK) to block 'disconnect' in that case - or is it expected behavior
> (nvme disconnect with force flag maybe) ?

None, I guess it should be something like _netdev fstab entry...

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-09 10:06 "nvme disconnect" for mounted volumes - stuck thread Szymon Scharmach
2019-09-09 19:31 ` Sagi Grimberg

Linux-NVME Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nvme/0 linux-nvme/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nvme linux-nvme/ https://lore.kernel.org/linux-nvme \
		linux-nvme@lists.infradead.org linux-nvme@archiver.kernel.org
	public-inbox-index linux-nvme


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-nvme


AGPL code for this site: git clone https://public-inbox.org/ public-inbox