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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 59985C47409 for ; Tue, 21 Jan 2020 00:56:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ECB2924125 for ; Tue, 21 Jan 2020 00:56:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lq3pSIbP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECB2924125 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 50F2C6B069D; Mon, 20 Jan 2020 19:56:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BFD76B06A3; Mon, 20 Jan 2020 19:56:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D6556B06A4; Mon, 20 Jan 2020 19:56:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 26B8F6B069D for ; Mon, 20 Jan 2020 19:56:36 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id CBCAB2C2A for ; Tue, 21 Jan 2020 00:56:35 +0000 (UTC) X-FDA: 76399825950.24.boats15_1c747e6d1f226 X-HE-Tag: boats15_1c747e6d1f226 X-Filterd-Recvd-Size: 5827 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Jan 2020 00:56:35 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id t8so1004254iln.4 for ; Mon, 20 Jan 2020 16:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DSU92DS/yk36ylsfrVTivyXxIB5DGgZzKoQw5FMazZY=; b=lq3pSIbPrnnnlke+/4iOv3idDrtKaxngImB5W4zXOYg1EKO6Pp/w7whzo54rLNLeXD +upd7lCyLeHSvzSyTGOEZ71HRLKodR6Vq6Y+YZDRrqxQY6FpB2JSqglWu3jYaue8ENEF KVlRJxNOLvZvEVdMFQyQsqQsNkHhSowq+YUp9GmtW99GGM6pTonzZVhMoIzr0+I9PgT1 LHLkw3uXhT5pCCltzzyFk9YEGZuHNt0PgobNHpEXDqdkB9j9GIx1MFBmPfzi7lEZusgc trp5oxFAdOiZz4/VNfWdeu6+/xXPge3HxZ120zDU1x/Tc0n5mhiGTxLpvL7KElejcARN q7Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DSU92DS/yk36ylsfrVTivyXxIB5DGgZzKoQw5FMazZY=; b=ctuKneeP1mqAyXCCRMDR2JsBDC2YcWF9skmFR1D0aGkrqrZ2hAiDVlTcgPpuy0pg06 aSQFDP6pdmtLEQGXwzmpBkR5VKqmBzCFsNP3skiHHYHFDiZpV2c+w/BLLU0cOE7gxKdp 5BkQAHgKZhw3fIzZqYQIsgjbqE/4Toz4/2wQHQiw7P+MZkrBt9ugWeXGI0Hr/oWooor3 AsBWKDUF1DceHFGost0QYP01NtaIVMUUV4S3Y8Y2CzngqWjVnUJG7IQWqNDthZjHYNdV g0DJEO9v9z8A5NV8uzqLvpvDz5VX4XGwX6SddIHdxtbImEz35RHMledDdxzwnfIo/Pd2 tRRA== X-Gm-Message-State: APjAAAUUg1n616lXY0tzfdjd5M1hrLrokG9XTZRtytxiwRoVUMdqtgSf YisXZxBDYUdbj6J2gylr5SycjeDCGmRMEZoNoGE= X-Google-Smtp-Source: APXvYqw9x3JAIzpZdG5I877D51seRujGg/PdSB1zVxtbiLT765Kfy8muncBvKsCU7feAIIHxlvYj1DUTZ+EL8c5IAF4= X-Received: by 2002:a92:d642:: with SMTP id x2mr1533285ilp.169.1579568194666; Mon, 20 Jan 2020 16:56:34 -0800 (PST) MIME-Version: 1.0 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> <20191003153743.GA24657@fieldses.org> In-Reply-To: <20191003153743.GA24657@fieldses.org> From: Steve French Date: Mon, 20 Jan 2020 18:56:24 -0600 Message-ID: Subject: Re: Lease semantic proposal To: "J. Bruce Fields" Cc: Jeff Layton , Ira Weiny , linux-fsdevel , linux-xfs , linux-ext4@vger.kernel.org, linux-rdma@vger.kernel.org, LKML , linux-nvdimm@lists.01.org, linux-mm , Dave Chinner , Jan Kara , "Theodore Ts'o" , John Hubbard , Dan Williams , Jason Gunthorpe Content-Type: text/plain; charset="UTF-8" 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: Two common complaints about the current lease API is that for some of the common protocols like SMB3 there is the need to be able to pass in the lease request on open itself, and also to upgrade and downgrade leases (in SMB3 lease keys can be passed over the wire) and of course it would be helpful if information about whether a lease was aquired were returned on open (and create) to minimize syscalls. On Thu, Oct 3, 2019 at 11:00 AM J. Bruce Fields wrot= e: > > 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. > > > > > > Why would it be difficult? > > > > 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?). > > > > > > Why not add new commands with range arguments later if it turns out t= o > > > be necessary? > > > > 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. > > > > 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. Yes --=20 Thanks, Steve