On 10/17/19 8:34 AM, Dan Williams wrote:
On Wed, Oct 16, 2019 at 7:43 PM Aneesh Kumar K.V


....


The error is printed by generic code and the failures are due to fixed
size. We can't workaround that using vmalloc=<size> option.

Darn.

Ok, explain to me again how this patch helps. This just seems to delay
the inevitable failure a bit, but the end result is that the user
needs to pick and choose which namespaces to enable after the kernel
has tried to auto-probe namespaces.


Right now we map the entire namespace using I/O remap range while probing and if we find the namespace mode to be fsdax or devdax we unmap the namespace and map them back using direct-map range. This temporary mapping cause transient failures if two large namespaces were probed at the same time. We try to map the second names space in the I/O remap range while the first one is already mapped there. ie,

If we have two 6TB namespaces with an I/O remap range limit of 8TB. We can individually create these namespaces and enable/disable them because they are within the 8TB limit. But if we try to probe them together, and if namespace1 is already mapped in the I/O remap range we have only 2TB space left in the I/O remap range and trying to probe the second namespace at the same time fails due to lack of space to map the namespace during probing.

This is not an issue with raw/btt, because they keep the namespace always mapped in the I/O remap range and if we are able to create a namespace we can enable them together. (we do have the issue of creating large raw/btt namespace while other raw/btt namespaces are disabled and trying to enable them all together).

The fix proposed in this patch is to not map the full namespace range while probing. We just need to map the reserve block to find the namespace mode. Based on the detected namespace mode, we either use direct-map range or I/O range to map the full namespace.

-aneesh
_______________________________________________
Linux-nvdimm mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to