Messages in this thread | | | Date | Tue, 27 Oct 2015 09:19:30 +1100 | From | Dave Chinner <> | Subject | Re: [PATCH 5/5] block: enable dax for raw block devices |
| |
On Mon, Oct 26, 2015 at 05:56:30PM +0900, Dan Williams wrote: > On Mon, Oct 26, 2015 at 3:23 PM, Dave Chinner <david@fromorbit.com> wrote: > > Also, DAX access isn't a property of mmap - it's a property > > of the inode. We cannot do DAX access via mmap while mixing page > > cache based access through file descriptor based interfaces. This > > I why I'm adding an inode attribute (on disk) to enable per-file DAX > > capabilities - either everything is via the DAX paths, or nothing > > is. > > > > Per-inode control sounds very useful, I'll look at a similar mechanism > for the raw block case. > > However, still not quite convinced page-cache control is an inode-only > property, especially when direct-i/o is not an inode-property. That > said, I agree the complexity of handling mixed mappings of the same > file is prohibitive.
We didn't get that choice with direct IO - support via O_DIRECT was kinda inherited from other OS's(*). We still have all sorts of coherency problems between buffered/mmap/direct IO on the same file, and I'd really, really like to avoid making that same mistake again with DAX.
i.e. We have a choice with DAX right now that will allow us to avoid coherency problems that we know existi and can't solve right now. Making DAX and inode property rather than a application context property avoids those coherence problems as all access will play by the same rules....
(*)That said, some other OS's did O_DIRECT as an inode property (e.g. solaris) where O_DIRECT was only done if no other cached operations were required (e.g. mmap), and so the fd would transparently shift between buffered and O_DIRECT depending on external accesses to the inode. This was not liked because of it's unpredictable effect on CPU usage and IO latency....
> Sounds good, get blkdev_issue_flush() functional first and then worry > about building a more efficient solution on top.
*nod*
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| |