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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 8C691C31E5D for ; Mon, 17 Jun 2019 23:39:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 65898208C0 for ; Mon, 17 Jun 2019 23:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560814748; bh=RlVq9+goQiRTPf4XaFdqefcmZD/0IfQ59bc/PNBhVyA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=wpuUT14vk6Kh/T/+o6cu03szV33/JjX9j/23v7Bojb9HRoLRmVenbXKb5X1tBKu2Y iCl0Y7h3109Lp156czED/NqfgKWx8DeDV9fIia0nPkxpY7YqjIcaB1I/cQv6fzKSmJ k+6WxtLS7GIGNPR/oEaLmoTlPbi7n/a5rqveDjfs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728728AbfFQXjH (ORCPT ); Mon, 17 Jun 2019 19:39:07 -0400 Received: from mail-lj1-f180.google.com ([209.85.208.180]:39918 "EHLO mail-lj1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727850AbfFQXjG (ORCPT ); Mon, 17 Jun 2019 19:39:06 -0400 Received: by mail-lj1-f180.google.com with SMTP id v18so11093559ljh.6 for ; Mon, 17 Jun 2019 16:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2NrsuK+fQa59Rf3zJAPEk/DpTvNWtzgqr6c6Hq01cwY=; b=Im9oEjWyr/vEdz9cgtOyleEhoCBdeVCcp3kWvdMeHXiN7x58vAV8sjEQKDudUFBh8E RxS+frlO5CQUO7JQDQ8qkogDUdkU7fmgqa4eHgTl13Zom7kAUMVec5A8Ne1jWBPaYFpa rHkCrluVPIkibD3eDmgnHGA9jDsnp0HYN0hFo= 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; bh=2NrsuK+fQa59Rf3zJAPEk/DpTvNWtzgqr6c6Hq01cwY=; b=L5jFeEYAOKiH2wcWQSbMSYLzVKaHY7VK16mNcpEB1GniixYQAgZmfU4/Fy+sNfnz37 SwR5VtNbZcqU1hOuFD2bWoZSaLAxJvALsB3gSu+N2v2iilI//MPWceSOkIZ5FOJaMEUR YQtQbu2VSzHXivbsc5EJIVxCufthXNlrjMZ20/HOBuv2v2UeggS8Nvw7xHy/1CVIkktq QDuMYaUVkUnCj4/PWyotJOWsC7gpYiN5ijWD2tqu1b+yGBieVMoK1mltVStdADvXsYhS Y354FVkZE6oS+0MPJ0snBkCC7FyDbEB1CUqvI/ZrEfbG4Gh7NwFHJH4LxCZvNiGWd1Ep U/eQ== X-Gm-Message-State: APjAAAUwntRhPTjPZeQbtu7C3GTNpca2vyAzIgmXr4WnuiUgUJBPMlRg Ua81ab2ovfTbBFOwk7sAjueOz/UV0pU= X-Google-Smtp-Source: APXvYqye6hbasNlpA0VUmtB+8zrJJNEKW31XJUbcZIev6Ags7oC/Wdu9Epq6zDXOhPHnab5hoM4E3g== X-Received: by 2002:a2e:5548:: with SMTP id j69mr14780635ljb.48.1560814743594; Mon, 17 Jun 2019 16:39:03 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id s20sm1905083lfb.95.2019.06.17.16.39.00 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 16:39:01 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id a25so7830266lfg.2 for ; Mon, 17 Jun 2019 16:39:00 -0700 (PDT) X-Received: by 2002:a19:f808:: with SMTP id a8mr3385678lff.29.1560814740667; Mon, 17 Jun 2019 16:39:00 -0700 (PDT) MIME-Version: 1.0 References: <20190610191420.27007-1-kent.overstreet@gmail.com> <20190611011737.GA28701@kmo-pixel> <20190611043336.GB14363@dread.disaster.area> <20190612162144.GA7619@kmo-pixel> <20190612230224.GJ14308@dread.disaster.area> <20190613183625.GA28171@kmo-pixel> <20190613235524.GK14363@dread.disaster.area> <20190617224714.GR14363@dread.disaster.area> In-Reply-To: <20190617224714.GR14363@dread.disaster.area> From: Linus Torvalds Date: Mon, 17 Jun 2019 16:38:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: pagecache locking (was: bcachefs status update) merged) To: Dave Chinner Cc: Kent Overstreet , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Matthew Wilcox , Amir Goldstein , Jan Kara , Linux List Kernel Mailing , linux-xfs , linux-fsdevel , Josef Bacik , Alexander Viro , Andrew Morton Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Jun 17, 2019 at 3:48 PM Dave Chinner wrote: > > The wording of posix changes every time they release a new version > of the standard, and it's _never_ obvious what behaviour the > standard is actually meant to define. They are always written with > sufficient ambiguity and wiggle room that they could mean > _anything_. The POSIX 2017.1 standard you quoted is quite different > to older versions, but it's no less ambiguous... POSIX has always been pretty lax, partly because all the Unixes did things differently, but partly because it then also ended up about trying to work for the VMS and Windows posix subsystems.. So yes, the language tends to be intentionally not all that strict. > > The pthreads atomicity thing seems to be about not splitting up IO and > > doing it in chunks when you have m:n threading models, but can be > > (mis-)construed to have threads given higher atomicity guarantees than > > processes. > > Right, but regardless of the spec we have to consider that the > behaviour of XFS comes from it's Irix heritage (actually from EFS, > the predecessor of XFS from the late 1980s) Sure. And as I mentioned, I think it's technically the nicer guarantee. That said, it's a pretty *expensive* guarantee. It's one that you yourself are not willing to give for O_DIRECT IO. And it's not a guarantee that Linux has ever had. In fact, it's not even something I've ever seen anybody ever depend on. I agree that it's possible that some app out there might depend on that kind of guarantee, but I also suspect it's much much more likely that it's the other way around: XFS is being unnecessarily strict, because everybody is testing against filesystems that don't actually give the total atomicity guarantees. Nobody develops for other unixes any more (and nobody really ever did it by reading standards papers - even if they had been very explicit). And honestly, the only people who really do threaded accesses to the same file (a) don't want that guarantee in the first place (b) are likely to use direct-io that apparently doesn't give that atomicity guarantee even on xfs so I do think it's moot. End result: if we had a really cheap range lock, I think it would be a good idea to use it (for the whole QoI implementation), but for practical reasons it's likely better to just stick to the current lack of serialization because it performs better and nobody really seems to want anything else anyway. Linus