From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACC94C32792 for ; Thu, 3 Oct 2019 15:37:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 79F1F2133F for ; Thu, 3 Oct 2019 15:37:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79F1F2133F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fieldses.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0B52A6B0005; Thu, 3 Oct 2019 11:37:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03E946B0006; Thu, 3 Oct 2019 11:37:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E46568E0003; Thu, 3 Oct 2019 11:37:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id BA38C6B0005 for ; Thu, 3 Oct 2019 11:37:45 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 4A1F02C9D for ; Thu, 3 Oct 2019 15:37:45 +0000 (UTC) X-FDA: 76002878490.16.shape62_965afe9c1a03 X-HE-Tag: shape62_965afe9c1a03 X-Filterd-Recvd-Size: 3340 Received: from fieldses.org (fieldses.org [173.255.197.46]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Oct 2019 15:37:44 +0000 (UTC) Received: by fieldses.org (Postfix, from userid 2815) id 195AB322; Thu, 3 Oct 2019 11:37:43 -0400 (EDT) Date: Thu, 3 Oct 2019 11:37:43 -0400 From: "J. Bruce Fields" To: Jeff Layton Cc: Ira Weiny , linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-mm@kvack.org, Dave Chinner , Jan Kara , Theodore Ts'o , John Hubbard , Dan Williams , Jason Gunthorpe Subject: Re: Lease semantic proposal Message-ID: <20191003153743.GA24657@fieldses.org> References: <20190923190853.GA3781@iweiny-DESK2.sc.intel.com> <5d5a93637934867e1b3352763da8e3d9f9e6d683.camel@kernel.org> <20191001181659.GA5500@iweiny-DESK2.sc.intel.com> <2b42cf4ae669cedd061c937103674babad758712.camel@kernel.org> <20191002192711.GA21386@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 02, 2019 at 04:35:55PM -0400, Jeff Layton wrote: > On Wed, 2019-10-02 at 15:27 -0400, J. Bruce Fields wrote: > > On Wed, Oct 02, 2019 at 08:28:40AM -0400, Jeff Layton wrote: > > > For the byte ranges, the catch there is that extending the userland > > > interface for that later will be difficult. > >=20 > > Why would it be difficult? >=20 > Legacy userland code that wanted to use byte range enabled layouts woul= d > have to be rebuilt to take advantage of them. If we require a range fro= m > the get-go, then they will get the benefit of them once they're > available. I can't see writing byte-range code for a kernel that doesn't support that yet. How would I test it? > > > What I'd probably suggest > > > (and what would jive with the way pNFS works) would be to go ahead = and > > > add an offset and length to the arguments and result (maybe also > > > whence?). > >=20 > > Why not add new commands with range arguments later if it turns out t= o > > be necessary? >=20 > We could do that. It'd be a little ugly, IMO, simply because then we'd > end up with two interfaces that do almost the exact same thing. >=20 > Should byte-range layouts at that point conflict with non-byte range > layouts, or should they be in different "spaces" (a'la POSIX and flock > locks)? When it's all one interface, those sorts of questions sort of > answer themselves. When they aren't we'll have to document them clearly > and I think the result will be more confusing for userland programmers. I was hoping they'd be in the same space, with the old interface just defined to deal in locks with range [0,=E2=88=9E). I'm just worried about getting the interface wrong if it's specified without being implemented. Maybe this is straightforward enough that there's not a risk, I don't know. --b.