From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Jason Gunthorpe" <jgg@ziepe.ca>, "Jan Kara" <jack@suse.cz>,
linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org,
"Dave Chinner" <david@fromorbit.com>,
"Jeff Layton" <jlayton@kernel.org>,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, "Jérôme Glisse" <jglisse@redhat.com>,
"John Hubbard" <jhubbard@nvidia.com>,
linux-fsdevel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
linux-ext4@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
Date: Wed, 12 Jun 2019 16:30:24 -0700 [thread overview]
Message-ID: <20190612233024.GD14336@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20190612123751.GD32656@bombadil.infradead.org>
On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote:
> On Sat, Jun 08, 2019 at 10:10:36AM +1000, Dave Chinner wrote:
> > On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> > > Are you suggesting that we have something like this from user space?
> > >
> > > fcntl(fd, F_SETLEASE, F_LAYOUT | F_UNBREAKABLE);
> >
> > Rather than "unbreakable", perhaps a clearer description of the
> > policy it entails is "exclusive"?
> >
> > i.e. what we are talking about here is an exclusive lease that
> > prevents other processes from changing the layout. i.e. the
> > mechanism used to guarantee a lease is exclusive is that the layout
> > becomes "unbreakable" at the filesystem level, but the policy we are
> > actually presenting to uses is "exclusive access"...
>
> That's rather different from the normal meaning of 'exclusive' in the
> context of locks, which is "only one user can have access to this at
> a time". As I understand it, this is rather more like a 'shared' or
> 'read' lock. The filesystem would be the one which wants an exclusive
> lock, so it can modify the mapping of logical to physical blocks.
>
> The complication being that by default the filesystem has an exclusive
> lock on the mapping, and what we're trying to add is the ability for
> readers to ask the filesystem to give up its exclusive lock.
This is an interesting view...
And after some more thought, exclusive does not seem like a good name for this
because technically F_WRLCK _is_ an exclusive lease...
In addition, the user does not need to take the "exclusive" write lease to be
notified of (broken by) an unexpected truncate. A "read" lease is broken by
truncate. (And "write" leases really don't do anything different WRT the
interaction of the FS and the user app. Write leases control "exclusive"
access between other file descriptors.)
Another thing to consider is that this patch set _allows_ a truncate/hole punch
to proceed _if_ the pages being affected are not actually pinned. So the
unbreakable/exclusive nature of the lease is not absolute.
Personally I like this functionality. I'm not quite sure I can make it work
with what Jan is suggesting. But I like it.
Given the muddied water of "exclusive" and "write" lease I'm now feeling like
Jeff has a point WRT the conflation of F_RDLCK/F_WRLCK/F_UNLCK and this new
functionality.
Should we use his suggested F_SETLAYOUT/F_GETLAYOUT cmd type?[1]
Ira
[1] https://lkml.org/lkml/2019/6/9/117
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: "Jason Gunthorpe" <jgg-uk2M96/98Pc@public.gmane.org>,
"Jan Kara" <jack-AlSwsSmVLrQ@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Dave Chinner" <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
"Jeff Layton" <jlayton-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
"Jérôme Glisse" <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"John Hubbard" <jhubbard-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Theodore Ts'o" <tytso-3s7WtUTddSA@public.gmane.org>,
linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Andrew Morton"
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
Date: Wed, 12 Jun 2019 16:30:24 -0700 [thread overview]
Message-ID: <20190612233024.GD14336@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20190612123751.GD32656-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote:
> On Sat, Jun 08, 2019 at 10:10:36AM +1000, Dave Chinner wrote:
> > On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> > > Are you suggesting that we have something like this from user space?
> > >
> > > fcntl(fd, F_SETLEASE, F_LAYOUT | F_UNBREAKABLE);
> >
> > Rather than "unbreakable", perhaps a clearer description of the
> > policy it entails is "exclusive"?
> >
> > i.e. what we are talking about here is an exclusive lease that
> > prevents other processes from changing the layout. i.e. the
> > mechanism used to guarantee a lease is exclusive is that the layout
> > becomes "unbreakable" at the filesystem level, but the policy we are
> > actually presenting to uses is "exclusive access"...
>
> That's rather different from the normal meaning of 'exclusive' in the
> context of locks, which is "only one user can have access to this at
> a time". As I understand it, this is rather more like a 'shared' or
> 'read' lock. The filesystem would be the one which wants an exclusive
> lock, so it can modify the mapping of logical to physical blocks.
>
> The complication being that by default the filesystem has an exclusive
> lock on the mapping, and what we're trying to add is the ability for
> readers to ask the filesystem to give up its exclusive lock.
This is an interesting view...
And after some more thought, exclusive does not seem like a good name for this
because technically F_WRLCK _is_ an exclusive lease...
In addition, the user does not need to take the "exclusive" write lease to be
notified of (broken by) an unexpected truncate. A "read" lease is broken by
truncate. (And "write" leases really don't do anything different WRT the
interaction of the FS and the user app. Write leases control "exclusive"
access between other file descriptors.)
Another thing to consider is that this patch set _allows_ a truncate/hole punch
to proceed _if_ the pages being affected are not actually pinned. So the
unbreakable/exclusive nature of the lease is not absolute.
Personally I like this functionality. I'm not quite sure I can make it work
with what Jan is suggesting. But I like it.
Given the muddied water of "exclusive" and "write" lease I'm now feeling like
Jeff has a point WRT the conflation of F_RDLCK/F_WRLCK/F_UNLCK and this new
functionality.
Should we use his suggested F_SETLAYOUT/F_GETLAYOUT cmd type?[1]
Ira
[1] https://lkml.org/lkml/2019/6/9/117
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Dave Chinner" <david@fromorbit.com>, "Jan Kara" <jack@suse.cz>,
"Dan Williams" <dan.j.williams@intel.com>,
"Theodore Ts'o" <tytso@mit.edu>,
"Jeff Layton" <jlayton@kernel.org>,
linux-xfs@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-ext4@vger.kernel.org,
linux-mm@kvack.org, "Jason Gunthorpe" <jgg@ziepe.ca>,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
Date: Wed, 12 Jun 2019 16:30:24 -0700 [thread overview]
Message-ID: <20190612233024.GD14336@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20190612123751.GD32656@bombadil.infradead.org>
On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote:
> On Sat, Jun 08, 2019 at 10:10:36AM +1000, Dave Chinner wrote:
> > On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> > > Are you suggesting that we have something like this from user space?
> > >
> > > fcntl(fd, F_SETLEASE, F_LAYOUT | F_UNBREAKABLE);
> >
> > Rather than "unbreakable", perhaps a clearer description of the
> > policy it entails is "exclusive"?
> >
> > i.e. what we are talking about here is an exclusive lease that
> > prevents other processes from changing the layout. i.e. the
> > mechanism used to guarantee a lease is exclusive is that the layout
> > becomes "unbreakable" at the filesystem level, but the policy we are
> > actually presenting to uses is "exclusive access"...
>
> That's rather different from the normal meaning of 'exclusive' in the
> context of locks, which is "only one user can have access to this at
> a time". As I understand it, this is rather more like a 'shared' or
> 'read' lock. The filesystem would be the one which wants an exclusive
> lock, so it can modify the mapping of logical to physical blocks.
>
> The complication being that by default the filesystem has an exclusive
> lock on the mapping, and what we're trying to add is the ability for
> readers to ask the filesystem to give up its exclusive lock.
This is an interesting view...
And after some more thought, exclusive does not seem like a good name for this
because technically F_WRLCK _is_ an exclusive lease...
In addition, the user does not need to take the "exclusive" write lease to be
notified of (broken by) an unexpected truncate. A "read" lease is broken by
truncate. (And "write" leases really don't do anything different WRT the
interaction of the FS and the user app. Write leases control "exclusive"
access between other file descriptors.)
Another thing to consider is that this patch set _allows_ a truncate/hole punch
to proceed _if_ the pages being affected are not actually pinned. So the
unbreakable/exclusive nature of the lease is not absolute.
Personally I like this functionality. I'm not quite sure I can make it work
with what Jan is suggesting. But I like it.
Given the muddied water of "exclusive" and "write" lease I'm now feeling like
Jeff has a point WRT the conflation of F_RDLCK/F_WRLCK/F_UNLCK and this new
functionality.
Should we use his suggested F_SETLAYOUT/F_GETLAYOUT cmd type?[1]
Ira
[1] https://lkml.org/lkml/2019/6/9/117
next prev parent reply other threads:[~2019-06-12 23:29 UTC|newest]
Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 1:45 [PATCH RFC 00/10] RDMA/FS DAX truncate proposal ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 01/10] fs/locks: Add trace_leases_conflict ira.weiny
2019-06-09 12:52 ` Jeff Layton
2019-06-06 1:45 ` [PATCH RFC 02/10] fs/locks: Export F_LAYOUT lease to user space ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-09 13:00 ` Jeff Layton
2019-06-09 13:00 ` Jeff Layton
2019-06-11 21:38 ` Ira Weiny
2019-06-11 21:38 ` Ira Weiny
2019-06-12 9:46 ` Jan Kara
2019-06-06 1:45 ` [PATCH RFC 03/10] mm/gup: Pass flags down to __gup_device_huge* calls ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 6:18 ` Christoph Hellwig
2019-06-06 16:10 ` Ira Weiny
2019-06-06 1:45 ` [PATCH RFC 04/10] mm/gup: Ensure F_LAYOUT lease is held prior to GUP'ing pages ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 05/10] fs/ext4: Teach ext4 to break layout leases ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 06/10] fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 07/10] fs/ext4: Fail truncate if pages are GUP pinned ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 10:58 ` Jan Kara
2019-06-06 10:58 ` Jan Kara
2019-06-06 16:17 ` Ira Weiny
2019-06-06 1:45 ` [PATCH RFC 08/10] fs/xfs: Teach xfs to use new dax_layout_busy_page() ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 09/10] fs/xfs: Fail truncate if pages are GUP pinned ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 1:45 ` [PATCH RFC 10/10] mm/gup: Remove FOLL_LONGTERM DAX exclusion ira.weiny
2019-06-06 1:45 ` ira.weiny
2019-06-06 5:52 ` [PATCH RFC 00/10] RDMA/FS DAX truncate proposal John Hubbard
2019-06-06 5:52 ` John Hubbard
2019-06-06 17:11 ` Ira Weiny
2019-06-06 17:11 ` Ira Weiny
2019-06-06 19:46 ` Jason Gunthorpe
2019-06-06 10:42 ` Jan Kara
2019-06-06 15:35 ` Dan Williams
2019-06-06 19:51 ` Jason Gunthorpe
2019-06-06 22:22 ` Ira Weiny
2019-06-07 10:36 ` Jan Kara
2019-06-07 12:17 ` Jason Gunthorpe
2019-06-07 14:52 ` Ira Weiny
2019-06-07 14:52 ` Ira Weiny
2019-06-07 15:10 ` Jason Gunthorpe
2019-06-12 10:29 ` Jan Kara
2019-06-12 10:29 ` Jan Kara
2019-06-12 11:47 ` Jason Gunthorpe
2019-06-12 12:09 ` Jan Kara
2019-06-12 12:09 ` Jan Kara
2019-06-12 18:41 ` Dan Williams
2019-06-13 7:17 ` Jan Kara
2019-06-13 7:17 ` Jan Kara
2019-06-12 19:14 ` Jason Gunthorpe
2019-06-12 22:13 ` Ira Weiny
2019-06-12 22:54 ` Dan Williams
2019-06-12 22:54 ` Dan Williams
2019-06-12 23:33 ` Ira Weiny
2019-06-12 23:33 ` Ira Weiny
2019-06-13 1:14 ` Dan Williams
2019-06-13 1:14 ` Dan Williams
2019-06-13 15:13 ` Jason Gunthorpe
2019-06-13 16:25 ` Dan Williams
2019-06-13 16:25 ` Dan Williams
2019-06-13 17:18 ` Jason Gunthorpe
2019-06-13 16:53 ` Dan Williams
2019-06-13 16:53 ` Dan Williams
2019-06-13 15:12 ` Jason Gunthorpe
2019-06-13 7:53 ` Jan Kara
2019-06-13 7:53 ` Jan Kara
2019-06-12 18:49 ` Dan Williams
2019-06-12 18:49 ` Dan Williams
2019-06-13 7:43 ` Jan Kara
2019-06-06 22:03 ` Ira Weiny
2019-06-06 22:03 ` Ira Weiny
2019-06-06 22:26 ` Ira Weiny
2019-06-06 22:28 ` Dave Chinner
2019-06-07 11:04 ` Jan Kara
2019-06-07 18:25 ` Ira Weiny
2019-06-07 18:25 ` Ira Weiny
2019-06-07 18:25 ` Ira Weiny
2019-06-07 18:50 ` Jason Gunthorpe
2019-06-08 0:10 ` Dave Chinner
2019-06-08 0:10 ` Dave Chinner
2019-06-09 1:29 ` Ira Weiny
2019-06-09 1:29 ` Ira Weiny
2019-06-09 1:29 ` Ira Weiny
2019-06-12 12:37 ` Matthew Wilcox
2019-06-12 12:37 ` Matthew Wilcox
2019-06-12 12:37 ` Matthew Wilcox
2019-06-12 23:30 ` Ira Weiny [this message]
2019-06-12 23:30 ` Ira Weiny
2019-06-12 23:30 ` Ira Weiny
2019-06-13 0:55 ` Dave Chinner
2019-06-13 0:55 ` Dave Chinner
2019-06-13 0:55 ` Dave Chinner
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-14 3:42 ` Dave Chinner
2019-06-13 0:25 ` Dave Chinner
2019-06-13 0:25 ` Dave Chinner
2019-06-13 3:23 ` Matthew Wilcox
2019-06-13 3:23 ` Matthew Wilcox
2019-06-13 3:23 ` Matthew Wilcox
2019-06-13 4:36 ` Dave Chinner
2019-06-13 4:36 ` Dave Chinner
2019-06-13 4:36 ` Dave Chinner
2019-06-13 10:47 ` Matthew Wilcox
2019-06-13 10:47 ` Matthew Wilcox
2019-06-13 10:47 ` Matthew Wilcox
2019-06-13 15:29 ` Jason Gunthorpe
2019-06-13 15:27 ` Matthew Wilcox
2019-06-13 15:27 ` Matthew Wilcox
2019-06-13 15:27 ` Matthew Wilcox
2019-06-13 21:13 ` Ira Weiny
2019-06-13 21:13 ` Ira Weiny
2019-06-13 23:45 ` Jason Gunthorpe
2019-06-14 0:00 ` Ira Weiny
2019-06-14 0:00 ` Ira Weiny
2019-06-14 2:09 ` Dave Chinner
2019-06-14 2:09 ` Dave Chinner
2019-06-14 2:09 ` Dave Chinner
2019-06-14 2:31 ` Matthew Wilcox
2019-06-14 2:31 ` Matthew Wilcox
2019-06-14 3:07 ` Dave Chinner
2019-06-14 3:07 ` Dave Chinner
2019-06-14 3:07 ` Dave Chinner
2019-06-20 14:52 ` Jan Kara
2019-06-20 14:52 ` Jan Kara
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-13 20:34 ` Ira Weiny
2019-06-14 2:58 ` Dave Chinner
2019-06-14 2:58 ` Dave Chinner
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=20190612233024.GD14336@iweiny-DESK2.sc.intel.com \
--to=ira.weiny@intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=jlayton@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/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.