Re: [PATCH] ndctl: New structure definitions.

On Fri, Aug 11, 2017 at 10:58 AM, Linda Knippers wrote: > > On 8/11/2017 12:48 PM, Dan Williams wrote: >> >> On Fri, Aug 11, 2017 at 6:36 AM, Linda Knippers >> wrote: >>> >>> >>> >>> On 8/10/2017 10:27 PM, Dan Williams wrote: On Thu,

Re: [PATCH v4 7/8] libnvdimm: Adding blk-mq support to the pmem driver

On 08/11/2017 03:57 AM, Christoph Hellwig wrote: > On Mon, Aug 07, 2017 at 09:39:53AM -0700, Dave Jiang wrote: >> Adding blk-mq support to the pmem driver in addition to the direct bio >> support. > > Can you explain why this is only done for pmem and not btt and nd_blk? Only because I have

Re: [PATCH v4 8/8] libnvdimm: add DMA support for pmem blk-mq

On 08/11/2017 04:04 AM, Christoph Hellwig wrote: > On Mon, Aug 07, 2017 at 09:39:59AM -0700, Dave Jiang wrote: >> +static int queue_mode = PMEM_Q_MQ; > > So this changes the default for everyone. How about those systems > without dma engine? The code requests a DMA engine during

Re: [PATCH] ndctl: New structure definitions.

On 8/11/2017 12:48 PM, Dan Williams wrote: On Fri, Aug 11, 2017 at 6:36 AM, Linda Knippers wrote: On 8/10/2017 10:27 PM, Dan Williams wrote: On Thu, Aug 10, 2017 at 7:12 PM, Jerry Hoemann wrote: On Thu, Aug 10, 2017 at 05:47:10PM -0700,

Re: [PATCH v4 7/8] libnvdimm: Adding blk-mq support to the pmem driver

On Fri, Aug 11, 2017 at 3:57 AM, Christoph Hellwig wrote: > On Mon, Aug 07, 2017 at 09:39:53AM -0700, Dave Jiang wrote: >> Adding blk-mq support to the pmem driver in addition to the direct bio >> support. > > Can you explain why this is only done for pmem and not btt and

Re: [PATCH] ndctl: New structure definitions.

On Fri, Aug 11, 2017 at 6:36 AM, Linda Knippers wrote: > > > On 8/10/2017 10:27 PM, Dan Williams wrote: >> >> On Thu, Aug 10, 2017 at 7:12 PM, Jerry Hoemann >> wrote: >>> >>> On Thu, Aug 10, 2017 at 05:47:10PM -0700, Dan Williams wrote: On

[PATCH v3 5/6] xfs: toggle XFS_DIFLAG2_IOMAP_IMMUTABLE in response to fallocate

After validating the state of the file as not having holes, shared extents, or active mappings try to commit the XFS_DIFLAG2_IOMAP_IMMUTABLE flag to the on-disk inode metadata. If that succeeds then allow the S_IOMAP_IMMUTABLE to be set on the vfs inode. Cc: Jan Kara Cc: Jeff Moyer

[PATCH v3 3/6] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP

Provide an explicit fallocate operation type for clearing the S_IOMAP_IMMUTABLE flag. Like the enable case it requires CAP_IMMUTABLE and it can only be performed while no process has the file mapped. Cc: Jan Kara Cc: Jeff Moyer Cc: Christoph Hellwig

[PATCH v3 6/6] mm, xfs: protect swapfile contents with immutable + unwritten extents

On Jun 22, 2017, Darrick wrote: > On Jun 22, 2017, Dave wrote: >> Hmmm, I disagree on the unwritten state here. We want swap files to >> be able to use unwritten extents - it means we can preallocate the >> swap file and hand it straight to swapon without having to zero it

[PATCH v3 1/6] fs, xfs: introduce S_IOMAP_IMMUTABLE

An inode with this flag set indicates that the file's block map cannot be changed from the currently allocated set. The implementation of toggling the flag and sealing the state of the extent map is saved for a later patch. The functionality provided by S_IOMAP_IMMUTABLE, once toggle support is

[PATCH v3 4/6] xfs: introduce XFS_DIFLAG2_IOMAP_IMMUTABLE

Add an on-disk inode flag to record the state of the S_IOMAP_IMMUTABLE in-memory vfs inode flags. This allows the protections against reflink and hole punch to be automatically restored on a sub-sequent boot when the in-memory inode is established. The FS_XFLAG_IOMAP_IMMUTABLE is introduced to

[PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

>From falloc.h: FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the file logical-to-physical extent offset mappings in the file. The purpose is to allow an application to assume that there are no holes or shared extents in the file and that the metadata needed to

[PATCH v3 0/6] fs, xfs: block map immutable files

Changes since v2 [1]: * Rather than have an IS_IOMAP_IMMUTABLE() check in xfs_alloc_file_space(), place one centrally in xfs_bmapi_write() to catch all attempts to write the block allocation map. (Dave) * Make sealing an already sealed file, or unsealing an already unsealed file return

Re: [PATCH] ndctl: New structure definitions.

On 8/10/2017 10:27 PM, Dan Williams wrote: On Thu, Aug 10, 2017 at 7:12 PM, Jerry Hoemann wrote: On Thu, Aug 10, 2017 at 05:47:10PM -0700, Dan Williams wrote: On Thu, Aug 10, 2017 at 5:00 PM, Jerry Hoemann wrote: Add structure definitions

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Sun, Aug 06, 2017 at 11:51:50AM -0700, Dan Williams wrote: > Of course it's a useful API. An application already needs to worry > about the block map, that's why we have fallocate, msync, fiemap > and... Fallocate and msync do not expose the block map in any way. Proof: they work just fine

Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults

On Mon, Aug 07, 2017 at 05:24:08PM -0700, Dan Williams wrote: > Does sys_mmap() reject unknown flag values today? I'm either not > looking in the right place or it's missing and we'll need some > interface/mechanism to check if MAP_SYNC is honored. It doesn't seem to reject unknown flags. The

Re: [PATCH v4 7/8] libnvdimm: Adding blk-mq support to the pmem driver

On Mon, Aug 07, 2017 at 09:39:53AM -0700, Dave Jiang wrote: > Adding blk-mq support to the pmem driver in addition to the direct bio > support. Can you explain why this is only done for pmem and not btt and nd_blk? > This allows for hardware offloading via DMA engines. By default > the bio

Re: [PATCH v4 8/8] libnvdimm: add DMA support for pmem blk-mq

On Mon, Aug 07, 2017 at 09:39:59AM -0700, Dave Jiang wrote: > +static int queue_mode = PMEM_Q_MQ; So this changes the default for everyone. How about those systems without dma engine? > module_param(queue_mode, int, 0444); > -MODULE_PARM_DESC(queue_mode, "Pmem Queue Mode (0=BIO, 1=BLK-MQ)"); >

Re: [PATCH v2 1/5] fs, xfs: introduce S_IOMAP_IMMUTABLE

On Mon, Aug 07, 2017 at 10:25:02AM +1000, Dave Chinner wrote: > We've always told people not to do those "horrible abuses" because > of the TOCTOU race conditions inherent in getting accurate > BMAP/FIEMAP information to userspace. However, immutable extent maps > solve the TOCTOU problem and so

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

On Wed, Aug 09, 2017 at 08:06:24PM -0700, Dan Williams wrote: > I like it, but do you think we should switch to sbvec[] to > preclude pathological cases where nr_pages is large? Yes, please. Then I'd like to see that the on-stack bio even matters for mpage_readpage / mpage_writepage. Compared

����/����/���������������Ե�����

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

Re: [PATCH v5 6/7] libnvdimm, btt: refactor initial_offset calculations

On Tue, Aug 8, 2017 at 5:07 PM, Vishal Verma wrote: > In preparation for BTT error clearing, refactor the initial offset > calculations. Until now, all callers of arena_{read,write}_bytes assumed > a relative offset to the arena, and it was later adjusted for the >

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

On Fri, Aug 11, 2017 at 07:31:54PM -0700, Darrick J. Wong wrote: > On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote: > > On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote: > > > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner wrote: > > > > On Thu, Aug

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote: > >From falloc.h: > > FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the > file logical-to-physical extent offset mappings in the file. The > purpose is to allow an application to assume that there are no

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner wrote: > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote: >> >From falloc.h: >> >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the >> file logical-to-physical extent offset mappings in the

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote: > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner wrote: > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote: > >> >From falloc.h: > >> > >> FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable)

Re: [PATCH v3 2/6] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP

On Sat, Aug 12, 2017 at 10:30:34AM +1000, Dave Chinner wrote: > On Fri, Aug 11, 2017 at 04:42:18PM -0700, Dan Williams wrote: > > On Fri, Aug 11, 2017 at 4:27 PM, Dave Chinner wrote: > > > On Thu, Aug 10, 2017 at 11:39:28PM -0700, Dan Williams wrote: > > >> >From falloc.h: >

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig wrote: > On Sun, Aug 06, 2017 at 11:51:50AM -0700, Dan Williams wrote: >> Of course it's a useful API. An application already needs to worry >> about the block map, that's why we have fallocate, msync, fiemap >> and... > > Fallocate

Re: [PATCH v3 6/6] mm, xfs: protect swapfile contents with immutable + unwritten extents

On Thu, Aug 10, 2017 at 11:39:49PM -0700, Dan Williams wrote: > ifp = XFS_IFORK_PTR(ip, whichfork); > diff --git a/fs/xfs/libxfs/xfs_bmap.h b/fs/xfs/libxfs/xfs_bmap.h > index 851982a5dfbc..a0f099289520 100644 > --- a/fs/xfs/libxfs/xfs_bmap.h > +++ b/fs/xfs/libxfs/xfs_bmap.h > @@ -113,6

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams wrote: > On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig wrote: >> Please explain how this interface allows for any sort of safe userspace >> DMA. > > So this is where I continue to see S_IOMAP_IMMUTABLE

[PATCH 3/3] libnvdimm, pfn, dax: limit namespace alignments to the supported set

Now that we properly advertise the supported pte, pmd, and pud sizes, restrict the supported alignments that can be set on a namespace. This assumes that userspace was not previously relying on the ability to set odd alignments. At least ndctl only ever supported setting the namespace alignment to

[PATCH 2/3] libnvdimm, pfn, dax: show supported dax/pfn region alignments in sysfs

From: Oliver O'Halloran The alignment of a DAX and PFN regions dictates the page sizes that can be used to map the region. Even if the hardware page sizes are known the actual range of supported page sizes that can be used with DAX depends on the kernel configuration. As a

[PATCH 0/3] libnvdimm: export supported page size alignments

This series is a minor rework of Oliver's original patch: https://patchwork.kernel.org/patch/9811257/ It allows userspace to discover the system huge and gigantic page sizes for aligning devices to support larger than PAGE_SIZE mappings for dax. --- Dan Williams (2): libnvdimm: rename

[PATCH 1/3] libnvdimm: rename nd_sector_size_{show, store} to nd_size_select_{show, store}

Prepare for other another consumer of this size selection scheme that is not a 'sector size'. Cc: Oliver O'Halloran Signed-off-by: Dan Williams --- drivers/nvdimm/btt_devs.c |4 ++-- drivers/nvdimm/core.c | 10 +-

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Fri, Aug 11, 2017 at 8:57 PM, Andy Lutomirski wrote: > On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams > wrote: >> On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig wrote: >>> Please explain how this interface allows for any sort of

RE: [PATCH v4 0/8] Adding blk-mq and DMA support to pmem block driver

> -Original Message- > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf Of > Dave Jiang > Sent: Monday, August 7, 2017 11:39 AM > To: vinod.k...@intel.com; dan.j.willi...@intel.com > Cc: dmaeng...@vger.kernel.org; linux-nvdimm@lists.01.org > Subject: [PATCH v4 0/8]

Re: [PATCH v1 2/6] fs: use on-stack-bio if backing device has BDI_CAP_SYNC capability

On 08/11/2017 04:46 AM, Christoph Hellwig wrote: > On Wed, Aug 09, 2017 at 08:06:24PM -0700, Dan Williams wrote: >> I like it, but do you think we should switch to sbvec[] to >> preclude pathological cases where nr_pages is large? > > Yes, please. > > Then I'd like to see that the on-stack bio