From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Kara <jack@suse.com>, Matthew Wilcox <willy@linux.intel.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-nvdimm@lists.01.org,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v2 2/2] ext2: Add locking for DAX faults
Date: Wed, 14 Oct 2015 09:31:38 -0600 [thread overview]
Message-ID: <20151014153138.GA12470@linux.intel.com> (raw)
In-Reply-To: <20151014085119.GB23758@quack.suse.cz>
On Wed, Oct 14, 2015 at 10:51:19AM +0200, Jan Kara wrote:
> On Tue 13-10-15 16:25:37, Ross Zwisler wrote:
> > Add locking to ensure that DAX faults are isolated from ext2 operations
> > that modify the data blocks allocation for an inode. This is intended to
> > be analogous to the work being done in XFS by Dave Chinner:
> >
> > http://www.spinics.net/lists/linux-fsdevel/msg90260.html
> >
> > Compared with XFS the ext2 case is greatly simplified by the fact that ext2
> > already allocates and zeros new blocks before they are returned as part of
> > ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
> > unwritten buffer heads.
> >
> > This means that the only work we need to do in ext2 is to isolate the DAX
> > faults from inode block allocation changes. I believe this just means that
> > we need to isolate the DAX faults from truncate operations.
> >
> > The newly introduced dax_sem is intended to replicate the protection
> > offered by i_mmaplock in XFS. In addition to truncate the i_mmaplock also
> > protects XFS operations like hole punching, fallocate down, extent
> > manipulation IOCTLS like xfs_ioc_space() and extent swapping. Truncate is
> > the only one of these operations supported by ext2.
> >
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
>
> The patch looks good to me. Feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.com>
>
> Or I can push the patch through my tree as it seems to be independent of
> any other changes, am I right?
>
> Honza
Yep, it is independent of other patches. It'd be great if you pushed it up
through your tree, thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Kara <jack@suse.com>, Matthew Wilcox <willy@linux.intel.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-nvdimm@ml01.01.org,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v2 2/2] ext2: Add locking for DAX faults
Date: Wed, 14 Oct 2015 09:31:38 -0600 [thread overview]
Message-ID: <20151014153138.GA12470@linux.intel.com> (raw)
In-Reply-To: <20151014085119.GB23758@quack.suse.cz>
On Wed, Oct 14, 2015 at 10:51:19AM +0200, Jan Kara wrote:
> On Tue 13-10-15 16:25:37, Ross Zwisler wrote:
> > Add locking to ensure that DAX faults are isolated from ext2 operations
> > that modify the data blocks allocation for an inode. This is intended to
> > be analogous to the work being done in XFS by Dave Chinner:
> >
> > http://www.spinics.net/lists/linux-fsdevel/msg90260.html
> >
> > Compared with XFS the ext2 case is greatly simplified by the fact that ext2
> > already allocates and zeros new blocks before they are returned as part of
> > ext2_get_block(), so DAX doesn't need to worry about getting unmapped or
> > unwritten buffer heads.
> >
> > This means that the only work we need to do in ext2 is to isolate the DAX
> > faults from inode block allocation changes. I believe this just means that
> > we need to isolate the DAX faults from truncate operations.
> >
> > The newly introduced dax_sem is intended to replicate the protection
> > offered by i_mmaplock in XFS. In addition to truncate the i_mmaplock also
> > protects XFS operations like hole punching, fallocate down, extent
> > manipulation IOCTLS like xfs_ioc_space() and extent swapping. Truncate is
> > the only one of these operations supported by ext2.
> >
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
>
> The patch looks good to me. Feel free to add:
>
> Reviewed-by: Jan Kara <jack@suse.com>
>
> Or I can push the patch through my tree as it seems to be independent of
> any other changes, am I right?
>
> Honza
Yep, it is independent of other patches. It'd be great if you pushed it up
through your tree, thanks!
next prev parent reply other threads:[~2015-10-14 15:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 22:25 [PATCH v2 0/2] Add updated DAX locking to ext2 Ross Zwisler
2015-10-13 22:25 ` Ross Zwisler
2015-10-13 22:25 ` [PATCH v2 1/2] dax: dax_pfn_mkwrite() truncate race check Ross Zwisler
2015-10-13 22:25 ` Ross Zwisler
2015-10-14 5:25 ` Dave Chinner
2015-10-14 5:25 ` Dave Chinner
2015-10-14 8:40 ` Jan Kara
2015-10-14 8:40 ` Jan Kara
2015-10-14 22:53 ` Dave Chinner
2015-10-14 22:53 ` Dave Chinner
2015-10-16 7:55 ` Jan Kara
2015-10-16 7:55 ` Jan Kara
2015-10-14 17:26 ` Ross Zwisler
2015-10-14 17:26 ` Ross Zwisler
2015-10-13 22:25 ` [PATCH v2 2/2] ext2: Add locking for DAX faults Ross Zwisler
2015-10-13 22:25 ` Ross Zwisler
2015-10-14 8:51 ` Jan Kara
2015-10-14 8:51 ` Jan Kara
2015-10-14 15:31 ` Ross Zwisler [this message]
2015-10-14 15:31 ` Ross Zwisler
2015-10-19 12:47 ` Jan Kara
2015-10-19 12:47 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151014153138.GA12470@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=matthew.r.wilcox@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.