* Re: [PATCH v8 7/7] nvme: fix ns removal hang when failing to revalidate due to a transient error
[not found] ` <20190830055435.GB8492@lst.de>
@ 2019-08-30 18:03 ` Sagi Grimberg
0 siblings, 0 replies; only message in thread
From: Sagi Grimberg @ 2019-08-30 18:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Keith Busch, James Smart, linux-nvme, Hannes Reinecke
>>> After looking into various revalidate_disk refactoring I think we could
>>> do something simple like this to just ignore the non-fatal errors
>>> (won't apply as is, but you get the idea):
>>
>> This will quietly ignore errors even for the routine ns allocation path,
>> do we want that to happen?
>
> Why not? Why would we treat an -ENOMEM or transport error different
> when doing a scanning (e.g. because we have to reconnect) vs just when
> revalidating?
OK, I'll give that a shot because I think it solves the issue as well.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-08-30 18:04 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20190823055442.19148-1-sagi@grimberg.me>
[not found] ` <20190823055442.19148-8-sagi@grimberg.me>
[not found] ` <20190825013813.GC23887@lst.de>
[not found] ` <20190825205700.GA3911@lst.de>
[not found] ` <a7dca3f1-5b51-ac6a-cfee-2cb8a5e3718d@grimberg.me>
[not found] ` <20190830055435.GB8492@lst.de>
2019-08-30 18:03 ` [PATCH v8 7/7] nvme: fix ns removal hang when failing to revalidate due to a transient error Sagi Grimberg
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 NNTP newsgroup(s).