Implications of LV mode

[okartau]

Introduction of LV mode detaches provisioned volumes from being 1:1-mapped to namespaces,
and that affects multiple areas. Instead of repeating same story in different issues, let's
have one umbrella issue here.
LVolume is not directly mapped to namespace, means it's mode can not follow some namespace mode directly, therefore our plans like #22 or #23 will not work in per-namespace context.
The smallest context these can work is Region.
But how such Region-based mode setting could get configured?
Is it really needed?
Easiest/cleanest from driver POV, would be a driver-wide option for NamespaceMode, is it?

[okartau]

If we decide to implement "direct NVDIMM" mode as proposed by #26, then this mode will allow namespace-level context and thus btt/sector mode and individual mount options for dax, I believe. We can add this statement to pros/cons section of different modes.

[okartau]

To get namespace mode handling implemented correctly (currently, mode is undefined, thus defaulting to FSDAX, but dax-option is not given to mount, see #23):
I propose we create the concept of "namespacemode" maintained in the driver

• namespacemode is driver-global and selected with plugin-specific start-time option, with valid values fsdax or sector. If not selected, namespacemode=fsdax
• the mode is used for setting NVDIMM namespaces mode during creation
  As:
• namespaces creation is performed by separate binary.
• namespaces may exist already before driver starts.
  means driver can not guess pre-existing namespace modes, it has to walk through all existing namespaces and check the modes are same, and are same compared to given mode as argument.
  If all are same and match configured mode, then driver will set run-time namespacemode to this mode.
  If some/all modes are not same, there is a problem, should handle somehow.
• Expose error and refuse to run ?
• Try to still run with limited capacity ? (if some namespaces have correct mode): this means then
  going through existing PVols and leave/create only these which match. But this will mess up existing file systems, if there are any.
• Try to actively fix differeing modes via delete/create new ones?
  Note that handling of all scenarios tends to turn up to be complex.

Note that above plan implements namespacemode as global option (k8s-cluster level)
so that all Nodes, all Regions will be forced to same namespacemode.
Achieving narrower scope for namespacemode (Node level, Region level ?) would be possible in driver, but as configuring/testing/understanding of such system would become rather complex, makes it questionable is such investment reasonable.

[okartau]

first draft of adding namespacemode in driver pushed in #52.

[okartau]

I think all concerns raised here were addressed by recent namespacemode implementation, so I propose to close this

[okartau]

no objections, closing