Currently, presence of direct_access() in block_device_operations
indicates support of DAX on its block device. Because
block_device_operations is instantiated with 'const', this DAX
capablity may not be enabled conditinally.
In preparation for supporting DAX to device-mapper devices, add
QUEUE_F
Change mapped device to implement direct_access function,
dm_blk_direct_access(), which calls a target direct_access function.
'struct target_type' is extended to have target direct_access interface.
This function limits direct accessible size to the dm_target's limit
with max_io_len().
Extend 'st
Change dm-linear to implement direct_access function,
linear_direct_access(), which maps sector and calls direct_access
function of its physical target device.
Change dm-linear to sets 'dax_supported' when its target physical device
supports DAX.
Signed-off-by: Toshi Kani
Cc: Alasdair Kergon
Cc
This patch-set adds DAX support to device-mapper dm-linear devices
used by LVM. It works with LVM commands as follows:
- Creation of a logical volume with all DAX capable devices (such
as pmem) sets the logical volume DAX capable as well.
- Once a logical volume is set to DAX capable, the vol
On Wed, 2016-06-22 at 18:38 -0400, Mike Snitzer wrote:
> On Wed, Jun 22 2016 at 4:16P -0400,
> Kani, Toshimitsu wrote:
> >
> > On Wed, 2016-06-22 at 12:15 -0700, Dan Williams wrote:
> > >
> > > On Wed, Jun 22, 2016 at 10:44 AM, Kani, Toshimitsu
> > > wrote:
> > > >
> > > > On Tue, 2016-06-21
On Wed, Jun 22 2016 at 4:16P -0400,
Kani, Toshimitsu wrote:
> On Wed, 2016-06-22 at 12:15 -0700, Dan Williams wrote:
> > On Wed, Jun 22, 2016 at 10:44 AM, Kani, Toshimitsu
> > wrote:
> > > On Tue, 2016-06-21 at 14:17 -0400, Mike Snitzer wrote:
> > > >
> > > > On Tue, Jun 21 2016 at 11:44am -04
On Wed, 2016-06-22 at 12:15 -0700, Dan Williams wrote:
> On Wed, Jun 22, 2016 at 10:44 AM, Kani, Toshimitsu
> wrote:
> > On Tue, 2016-06-21 at 14:17 -0400, Mike Snitzer wrote:
> > >
> > > On Tue, Jun 21 2016 at 11:44am -0400,
> > > Kani, Toshimitsu wrote:
> > > >
> > > > On Tue, 2016-06-21 at 0
On Wed, Jun 22, 2016 at 10:44 AM, Kani, Toshimitsu wrote:
> On Tue, 2016-06-21 at 14:17 -0400, Mike Snitzer wrote:
>> On Tue, Jun 21 2016 at 11:44am -0400,
>> Kani, Toshimitsu wrote:
>> >
>> > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote:
>> > >
>> > > On Mon, Jun 20 2016 at 6:22pm -040
On Tue, 2016-06-21 at 14:17 -0400, Mike Snitzer wrote:
> On Tue, Jun 21 2016 at 11:44am -0400,
> Kani, Toshimitsu wrote:
> >
> > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote:
> > >
> > > On Mon, Jun 20 2016 at 6:22pm -0400,
> > > Mike Snitzer wrote:
:
> > > I'm now wondering if we'd
On Tue, Jun 21, 2016 at 11:38 PM, Bart Van Assche
wrote:
> On 06/21/2016 10:46 PM, Dan Williams wrote:
>>
>> In preparation for the removal of 'driverfs_dev' from 'struct gendisk',
>> carry this data in mmc_blk_data. It is used for registration of parent
>> disks and partitions.
>>
>> Cc: Ulf Hans
So far the DAX code overloaded the direct I/O code path. There is very little
in common between the two, and untangling them allows to clean up both variants.
As a ѕide effect we also get separate trace points for both I/O types.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_file.c | 139 ++
We control both the callers and callees of ->direct_IO, so remove the
indirect calls.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_aops.c | 24 +---
fs/xfs/xfs_aops.h | 3 +++
fs/xfs/xfs_file.c | 17 +++--
3 files changed, 23 insertions(+), 21 deletions(-)
di
So far DAX writes inherited the locking from direct I/O writes, but the direct
I/O model of using shared locks for writes is actually wrong for DAX. For
direct I/O we're out of any standards and don't have to provide the Posix
required exclusion between writers, but for DAX which gets transparentl
The last patch is what started the series: XFS currently uses the
direct I/O locking strategy for DAX because DAX was overloaded onto
the direct I/O path. For XFS this means that we only take a shared
inode lock instead of the normal exclusive one for writes IFF they
are properly aligned. While
XFS already implement it's own flushing of the pagecache because it
implements proper synchronization for direct I/O reads. This means
calling generic_file_read_iter for direct I/O is rather useless,
as it doesn't do much but updating the atime and iocb position for
us. This also gets rid of the
Instead check the file pointer for the invisble I/O flag directly, and
use the chance to drop redundant arguments from the xfs_ioc_space
prototype.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_ioctl.c | 22 --
fs/xfs/xfs_ioctl.h | 3 ---
fs/xfs/xfs_ioctl32.c | 6 +---
Similar to what we did on the write side a while ago.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_file.c | 83 ++-
1 file changed, 57 insertions(+), 26 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 09a5a78..e584333
All the three low-level read implementations that we might call already
take care of not overflowing the maximum supported bytes, no need to
duplicate it here.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_file.c | 8
1 file changed, 8 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs
Now that we have the direct I/O kiocb flag there is no real need to sample
the value inside of XFS, and the invis flag was always just partially used
and isn't worth keeping this infrastructure around for. This also splits
the read tracepoint into buffered vs direct as we've done for writes a lon
On Tue, Jun 21, 2016 at 11:20 PM, Bart Van Assche
wrote:
> On 06/21/2016 10:47 PM, Dan Williams wrote:
>>
>> In preparation for the removal of 'driverfs_dev' from 'struct gendisk'
>> use a local variable to track the parented vs un-parented case in
>> ubd_disk_register().
>>
>> Cc: Jeff Dike
>> C
20 matches
Mail list logo
