On Fri, Jun 14, 2019 at 10:09 AM Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > > "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes: > > > On 6/14/19 10:06 PM, Dan Williams wrote: > >> On Fri, Jun 14, 2019 at 9:26 AM Aneesh Kumar K.V > >> <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > > >>> Why not let the arch > >>> arch decide the SUBSECTION_SHIFT and default to one subsection per > >>> section if arch is not enabled to work with subsection. > >> > >> Because that keeps the implementation from ever reaching a point where > >> a namespace might be able to be moved from one arch to another. If we > >> can squash these arch differences then we can have a common tool to > >> initialize namespaces outside of the kernel. The one wrinkle is > >> device-dax that wants to enforce the mapping size, > > > > The fsdax have a much bigger issue right? The file system block size > > is the same as PAGE_SIZE and we can't make it portable across archs > > that support different PAGE_SIZE? > > File system blocks are not tied to page size. They can't be *bigger* > than the page size currently, but they can be smaller. > > Still, I don't see that as an arugment against trying to make the > namespaces work across architectures. Consider a user who only has > sector mode namespaces. We'd like that to work if at all possible. Even with fsdax namespaces I don't see the concern. Yes, DAX might be disabled if the filesystem on the namespace has a block size that is smaller than the current system PAGE_SIZE, but the filesystem will still work. I.e. it's fine to put a 512 byte block size filesystem on a system that has a 4K PAGE_SIZE, you only lose DAX operations, not your data access.
