On Sun, Jul 31, 2016 at 09:39:38PM -0700, Dan Williams wrote: > On Sun, Jul 31, 2016 at 9:07 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > OTOH, DAX directly exposes the physical layout to the filesytem. > > And because it's DAX-based pmem and not cached struct pages, we > > can't run vm_map_ram() to virtually map the range we need to see as > > a contiguous range, as we do in XFS for large objects such as directory > > blocks and log buffers. For other large objects such as inode > > clusters, we can directly map each page as the objects within the > > clusters are page aligned and never overlap page boundaries, but > > that only works for inode and dquot buffers. Hence DAX as it stands > > makes it extremely difficult to "retrofit" DAX into all aspects of > > existing fileystems because exposing physical discontiguities breaks > > code that assumes they don't exist. > > On this specific point about page remapping, the administrator can > configure struct pages for pmem and you can detect whether they are > present in the filesystem with pfn_t_has_page(). I.e. you could > require pages be present for XFS, if that helps... It's kinda silly to require struct pages for the entire pmem device if they are only needed for accessing a (comparitively) small amount of metadata. Besides, now that I look at it more deeply, we can't use virtually mapped pmem for the log buffers. We can't allocate memory at the point in time where we work out what LBA in the log we need to map to physical pmem for the current log write. Hence calls to vm_map_ram() can't be used, and so that rules out using mapped page based pmem for log buffers. I'll probably have to rewrite the xlog_write() engine completely to be able to handle discontiguous pages in the iclog buffers before we can consider mapping them via DAX now, and I'm really not sure it's worth the effort. I'd much prefer to spend time designing a native pmem filesystem.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
