From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: [RFC PATCH 0/6] xfs: DAX support Date: Wed, 4 Mar 2015 10:30:21 +1100 Message-ID: <1425425427-16283-1-git-send-email-david@fromorbit.com> Cc: linux-fsdevel@vger.kernel.org, jack@suse.cz, willy@linux.intel.com To: xfs@oss.sgi.com Return-path: Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:43321 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757785AbbCCXbO (ORCPT ); Tue, 3 Mar 2015 18:31:14 -0500 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi folks, This is the first pass I've made for supporting DAX in XFS. Most of the XFS changes are straight forward and fairly self contained, and mostly seem to work. The first patch, however, is changing the DAX infrastructure to take a "block zeroing completion" function for dax_fault() so that we don't need to abuse the mapping bufferhead to pass the completion function. This is straight forward for XFS, but the ext4 code is, well, it's already broken so I don't think I've made anything worse. I note that Jan Kara is aware of the problems related to the unwritten extent conversion in ext4, as mentioned here earlier today on the ext4 list (items 1 and 2): http://permalink.gmane.org/gmane.comp.file-systems.ext4/47943 So really my only concern here is cleaning up the interface to remove the mapping bh hack, not whether ext4 works reliably or not. The XFS implementation does not have any of the problems the ext4 code does. The rest of the series adds all the DAX hooks into the required code paths for block zeroing, page fault, io, truncate and finally the mount path for the dax mount option. The series passes xfstests without and serious problems - there are a couple of tests where the extent layout isn't as the tests expect, but these are minor issues that don't affect correctness. Comments welcome, especially on the this dax_fault callback patch. -Dave.