Delivery reports about your e-mail

___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v4 08/18] tools/testing/nvdimm: add 'bio_delay' mechanism

Jan Kara writes: > On Tue 02-01-18 13:51:49, Dan Williams wrote: >> On Tue, Jan 2, 2018 at 1:44 PM, Dave Chinner wrote: >> > On Sat, Dec 23, 2017 at 04:56:43PM -0800, Dan Williams wrote: >> >> In support of testing truncate colliding with dma add a mechanism

Re: [PATCH v4 12/18] xfs: use DEFINE_FSDAX_AOPS

On Tue 02-01-18 13:40:32, Dan Williams wrote: > On Tue, Jan 2, 2018 at 1:15 PM, Darrick J. Wong > wrote: > > On Sat, Dec 23, 2017 at 04:57:04PM -0800, Dan Williams wrote: > >> In preparation for the dax implementation to start associating dax pages > >> to inodes via

Re: [PATCH v4 11/18] fs, dax: introduce DEFINE_FSDAX_AOPS

On Tue 02-01-18 12:21:28, Dan Williams wrote: > >> +EXPORT_SYMBOL(dax_set_page_dirty); > >> +EXPORT_SYMBOL(dax_direct_IO); > >> +EXPORT_SYMBOL(dax_writepage); > >> +EXPORT_SYMBOL(dax_readpage); > >> +EXPORT_SYMBOL(dax_readpages); > >> +EXPORT_SYMBOL(dax_write_begin); > >>

Re: [PATCH v4 08/18] tools/testing/nvdimm: add 'bio_delay' mechanism

On Tue 02-01-18 13:51:49, Dan Williams wrote: > On Tue, Jan 2, 2018 at 1:44 PM, Dave Chinner wrote: > > On Sat, Dec 23, 2017 at 04:56:43PM -0800, Dan Williams wrote: > >> In support of testing truncate colliding with dma add a mechanism that > >> delays the completion of

Re: [PATCH v4 07/18] dax: store pfns in the radix

On Sat 23-12-17 16:56:38, Dan Williams wrote: > In preparation for examining the busy state of dax pages in the truncate > path, switch from sectors to pfns in the radix. > > Cc: Jan Kara > Cc: Jeff Moyer > Cc: Christoph Hellwig > Cc: Matthew

Re: [PATCH v4 04/18] dax: require 'struct page' by default for filesystem dax

On Sat 23-12-17 16:56:22, Dan Williams wrote: > If a dax buffer from a device that does not map pages is passed to > read(2) or write(2) as a target for direct-I/O it triggers SIGBUS. If > gdb attempts to examine the contents of a dax buffer from a device that > does not map pages it triggers

Re: [PATCH v4 05/18] dax: stop using VM_MIXEDMAP for dax

On Sat 23-12-17 16:56:27, Dan Williams wrote: > VM_MIXEDMAP is used by dax to direct mm paths like vm_normal_page() that > the memory page it is dealing with is not typical memory from the linear > map. The get_user_pages_fast() path, since it does not resolve the vma, > is already using

Re: [PATCH v4 03/18] ext2: auto disable dax instead of failing mount

On Sat 23-12-17 16:56:17, Dan Williams wrote: > Bring the ext2 filesystem in line with xfs that only warns and continues > when the "-o dax" option is specified to mount and the backing device > does not support dax. This is in preparation for removing dax support > from devices that do not enable

Re: [PATCH v4 02/18] ext4: auto disable dax instead of failing mount

On Sat 23-12-17 16:56:11, Dan Williams wrote: > Bring the ext4 filesystem in line with xfs that only warns and continues > when the "-o dax" option is specified to mount and the backing device > does not support dax. This is in preparation for removing dax support > from devices that do not enable

[PATCH 0/2 v3] ext4: Fix ENOSPC handling for DAX faults

Hello, these two patches fix handling of ENOSPC during DAX faults. The problem is that currently running transaction may be holding lots of already freed blocks which can be reallocated only once the transaction commits. Standard retry logic in ext4_iomap_end() does not work for DAX page fault

[PATCH 1/2] dax: Pass detailed error code from dax_iomap_fault()

Ext4 needs to pass through error from its iomap handler to the page fault handler so that it can properly detect ENOSPC and force transaction commit and retry the fault (and block allocation). Add argument to dax_iomap_fault() for passing such error. Reviewed-by: Ross Zwisler

[PATCH 2/2] ext4: Fix ENOSPC handling in DAX page fault handler

When allocation of underlying block for a page fault fails, we fail the fault with SIGBUS. However we may well hit ENOSPC just due to lots of free blocks being held by the running / committing transaction. So propagate the error from ext4_iomap_begin() and implement do standard allocation retry