On 11/16/18 10:49 AM, Christoph Hellwig wrote:
On Fri, Nov 16, 2018 at 10:40:40AM +0100, Hannes Reinecke wrote:
Introduce ability to always re-read ANA log page as required due to ANA
error and make current ANA state available via sysfs -- even if native
multipathing is disabled on the host (e.g. nvme_core.multipath=N).
The first part I could see, but I still want to make it conditional
in some way as nvme is going into deeply embedded setups, and I don't
want to carry the weight of the ANA code around for everyone.
Can you clarify this a bit?
We _do_ have the NVME multipath config option to deconfigure the whole
thing during compile time; that isn't influenced with this patch.
So are you worried about the size of the ANA implementation itself?
Or are you worried about the size of the ANA structures?
I just see the next step of wanting to move ANA code into the core
which is implied above.
Really, I couldn't care less _where_ the ANA code lives.
If the size of which is any concern we can even make it configurable of
sorts.
The second I fundamentally disagree with. And even if you found agreement
it would have to be in a separate patch as it is a separate feature.
Why? Where's the problem with re-reading the ANA log pages if we get an
event indicating that we should?
"second" here means the sysfs file.
Ok, so would you be happy with making ANA support configurable?
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
