From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ira Weiny Subject: Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal Date: Sat, 8 Jun 2019 18:29:32 -0700 Message-ID: <20190609012931.GA19825@iweiny-DESK2.sc.intel.com> References: <20190606014544.8339-1-ira.weiny@intel.com> <20190606104203.GF7433@quack2.suse.cz> <20190606220329.GA11698@iweiny-DESK2.sc.intel.com> <20190607110426.GB12765@quack2.suse.cz> <20190607182534.GC14559@iweiny-DESK2.sc.intel.com> <20190608001036.GF14308@dread.disaster.area> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190608001036.GF14308-pA1nmv6sEBkOM8BvhN4Z8vybgvtCy99p@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dave Chinner Cc: Jason Gunthorpe , Theodore Ts'o , linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, John Hubbard , Jeff Layton , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matthew Wilcox , linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, =?iso-8859-1?B?Suly9G1l?= Glisse , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jan Kara , linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton List-Id: linux-rdma@vger.kernel.org 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: > > On Fri, Jun 07, 2019 at 01:04:26PM +0200, Jan Kara wrote: > > > On Thu 06-06-19 15:03:30, Ira Weiny wrote: > > > > On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote: > > > > > On Wed 05-06-19 18:45:33, ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote: > > > > > > From: Ira Weiny > > > > > > > > > > So I'd like to actually mandate that you *must* hold the file lease until > > > > > you unpin all pages in the given range (not just that you have an option to > > > > > hold a lease). And I believe the kernel should actually enforce this. That > > > > > way we maintain a sane state that if someone uses a physical location of > > > > > logical file offset on disk, he has a layout lease. Also once this is done, > > > > > sysadmin has a reasonably easy way to discover run-away RDMA application > > > > > and kill it if he wishes so. > > > > > > > > Fair enough. > > > > > > > > I was kind of heading that direction but had not thought this far forward. I > > > > was exploring how to have a lease remain on the file even after a "lease > > > > break". But that is incompatible with the current semantics of a "layout" > > > > lease (as currently defined in the kernel). [In the end I wanted to get an RFC > > > > out to see what people think of this idea so I did not look at keeping the > > > > lease.] > > > > > > > > Also hitch is that currently a lease is forcefully broken after > > > > /lease-break-time. To do what you suggest I think we would need a new > > > > lease type with the semantics you describe. > > > > > > I'd do what Dave suggested - add flag to mark lease as unbreakable by > > > truncate and teach file locking core to handle that. There actually is > > > support for locks that are not broken after given timeout so there > > > shouldn't be too many changes need. > > > > > > > Previously I had thought this would be a good idea (for other reasons). But > > > > what does everyone think about using a "longterm lease" similar to [1] which > > > > has the semantics you proppose? In [1] I was not sure "longterm" was a good > > > > name but with your proposal I think it makes more sense. > > > > > > As I wrote elsewhere in this thread I think FL_LAYOUT name still makes > > > sense and I'd add there FL_UNBREAKABLE to mark unusal behavior with > > > truncate. > > > > Ok I want to make sure I understand what you and Dave are suggesting. > > > > 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 sounds good. Ira > > Cheers, > > Dave. > -- > Dave Chinner > david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org