Re: [PATCH 2 2/2] xfs: fix rt_dev usage for DAX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 6, 2018 at 3:19 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> On Tue, Feb 06, 2018 at 03:32:00PM -0700, Dave Jiang wrote:
[..]
> The last time I paid much attention to DAX was the thread "re-enable XFS
> per-inode DAX"[1] last September.  Motivating me to merge anything else
> into DAX involves convincing me that we (mm, fs, dax developers) have
> some kind of agreement about what we want the user-visible interfaces to
> DAX to look like.  Namely:
>
> 0. On what level do we allow users / administrators to control usage of
> the dax paths?  Can the hardware convey enough detail to the kernel that
> the kernel can make a reasonable decision on its own whether buffered or
> dax io make more sense?  If so, can we please just have that?  If not,
> why?
>
> 1. If we want to let users override whatever decision the kernel makes,
> how should we do this?  One mount option that applies to everything,
> like ext4?  Inheritable inode flags, like xfs?  Do we have one to force
> it on even if the kernel doesn't want to?  Do we have another to force
> it off even if the kernel wants to?  Do we even want to go down this
> path?  Can we get away with making the answer to Q0 "yes" and then see
> if anyone actually complains about not having fine-grained control?

I think we will always have folks that want to force it on, i.e. the
MAP_SYNC user crowd. However, I think we might have some people what
will complain if they can't force it off. For example, I'm in the
process of killing off support for passing filesystem-dax mappings
through to guests because VFIO has the same "pin pages / fs-blocks
forever" problem as RDMA. Passing page cache through to a guest works
fine and it would be a shame if that silently stopped working in the
future. Given the page pinning constraint I'm not sure we can ever
support dynamically enabling DAX behind the user's back, at least not
until we kill off any "pin pages / fs-blocks forever" users, or
otherwise convert them to take a lease.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux