Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1039233imm; Wed, 17 Oct 2018 12:15:27 -0700 (PDT) X-Google-Smtp-Source: ACcGV62n9jOYrIyqhBRV3snHadupnHE20a+BZpr00GhmLXXcAxznaH3BxlAff8sm0PmKVRKcOoCj X-Received: by 2002:a62:8708:: with SMTP id i8-v6mr27631484pfe.150.1539803727536; Wed, 17 Oct 2018 12:15:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539803727; cv=none; d=google.com; s=arc-20160816; b=GQIH+6SMPw2yfl52YsrWi3s4kQfIfhpm4H7DNb38+5KSLxf0FfF/ORvGxJC+td5q55 f1vVt323azdurl9vbF1PB7TLRPdlGwGz7J5Sbl2MnRf1JBniBmWZRGnYHZfqYigu8wp9 m24Cs2izAxGmS6MFgAwbbwHVlCrjUM6nxr3nIVtCfdaJlAYzI5c6Vfq0n9NtjzCx71Rn ZXSamyDuu3/VYRY0zgFCHYFRJ4Cbli9dfTm2EerQLUV7AinKipW2Mpirse4FD4eg45wY HuKoTXD8eFJXAxZkNde8wkoaDTk2wPQTNh1UAoP055gjkzyTpN8K4YFL2rEjsFcyCD6I F88A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=UdE+IhzO9w1b99QSn8+Vi4bVlAuA8dqyG0qOb8ZWjKg=; b=WBJbhyFa4eYkPmgqswuP3qhTnsQhd9/fsdWo8aqd1YP2kr/Ta/Z8lhKV1Br7a/AjfY JWPl61CUEYFbgso0XhnSDsvrZE8x5n7CyC99ATHccBA6u2NJDLnUHJixY+FMUeedwc8Q ftehaoCuR5u1b0Ba157lXvouEmxZiLLAKvNkuP2gQYGf6peK3U7ybxZlL6ywTM0wMwFs P6zzHcpzIugEWL5fitEqgg7gVloFdPd4ceCg3ssAJYZmgFIHEFyUQKyBacmp8XbZh5k0 3gXZFadnY3+QXz96XL3UF0Z/GD37fh4a+c7rpn76y5DRFfwgh7j3saF3GfE3a536Zc4C Sdmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=OtQLwcKs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b13-v6si18395584pgj.154.2018.10.17.12.15.11; Wed, 17 Oct 2018 12:15:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=OtQLwcKs; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728374AbeJRDJ5 (ORCPT + 99 others); Wed, 17 Oct 2018 23:09:57 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:44954 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727271AbeJRDJ4 (ORCPT ); Wed, 17 Oct 2018 23:09:56 -0400 Received: by mail-io1-f67.google.com with SMTP id s6-v6so8889863ioa.11 for ; Wed, 17 Oct 2018 12:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UdE+IhzO9w1b99QSn8+Vi4bVlAuA8dqyG0qOb8ZWjKg=; b=OtQLwcKslQOTFOAwhYLUvumiTGGqyqAlPn/8qpw8Ze2PC0tVUXjKUF0lkwbewEDo54 eWE45OAsLWGdSwgyhxOV2+WcwFdaEDxhpKzgUjv5nLvwyDH2n/Bc1jGlmSwI9jnv4e7f jmkg6Y5HL6DzNK4+LGZVvKKhYQKA0sfAOZMmo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UdE+IhzO9w1b99QSn8+Vi4bVlAuA8dqyG0qOb8ZWjKg=; b=E6gkosEdFLQMRfyJQDOrAoPINfVHwjrspDN66yWl5513JVJSmBQuj9e183LCZ29XXA TKxMM5RNef2JFepW2DT/7pPXSHSeFOaBUzOri6efpH5AxADb9o1Wi2qiRGJ0zLH9PCoe ZtRQjMl0N0iIyrP5ZXWG0TKlzv2dRdHNSzxkSTDK5Rabs8eceDZfU6vF3yuY5kJxePz3 hpqJSW1KAyAKTbVsqkVRCAfU/lCvAQ7URDuhYkFZPlXGE9FaR1a46CZLM7ytHRHFqUAF 8+GPpRQQw2HKdhGCBlRjyJHMwF+zmeUV+ARaruw1LwV4BSBXiVta7vgPLaLsuOWUp711 GyZA== X-Gm-Message-State: ABuFfogA0eBHyB6h5KTG00QutojARsf0yDC+AVJcHi+1NzF+sCTsHPl3 r5pY9G9d93QZ7YlcmP2BQDR7nLrrXkQa7leSzgdq1A== X-Received: by 2002:a5e:8b06:: with SMTP id g6-v6mr14950348iok.144.1539803078141; Wed, 17 Oct 2018 12:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf41:0:0:0:0:0 with HTTP; Wed, 17 Oct 2018 12:04:37 -0700 (PDT) X-Originating-IP: [212.96.48.140] In-Reply-To: <006890C4-64D4-4DE2-A1F0-335FFFD585BB@dilger.ca> References: <006890C4-64D4-4DE2-A1F0-335FFFD585BB@dilger.ca> From: Miklos Szeredi Date: Wed, 17 Oct 2018 21:04:37 +0200 Message-ID: Subject: Re: statx(2) API and documentation To: Andreas Dilger Cc: Michael Kerrisk , David Howells , Linux FS-devel Mailing List , Linux Kernel Mailing List , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 17, 2018 at 8:45 PM, Andreas Dilger wrote: > On Oct 17, 2018, at 12:24 PM, Miklos Szeredi wrote: >> >> I'm trying to implement statx for fuse and ran into the following issues: >> >> - Need a STATX_ATTRIBUTES bit, so that userspace can explicitly ask >> for stx_attribute; otherwise if querying has non-zero cost, then >> filesystem cannot do it without regressing performance. > > Seems reasonable. > >> - STATX_ALL definition is unclear, can this change, or is it fixed? >> If it's the former, than that's a backward compatibility nightmare. >> If it's the latter, then what's the point? > > The value can change over time. It is intended to reflect the current > state of affairs at the time the userspace program and kernel are compiled. > The value sent from userspace lets the kernel know what fields are in > the userspace struct, so it doesn't try to set fields that aren't there. What's the point of a userspace program specifying STATX_ALL? Without a way to programmatically query the interface definition it's useless: there's no way to guess which mask bit corresponds to which field, and what that field represents. And there will be programs out there which specify STATX_ALL without considering that in the future it may become slower as it is now due to a recompile. So what's the point exactly? > The value in the kernel allows masking off new fields from userspace that > it doesn't understand. Okay, but that has nothing to do with the UAPI. Even as an internal flag we should be careful, as it might grow uses which can have similar issues as the userspace one above. > >> - STATX_ATIME is cleared from stx_mask on SB_RDONLY, and on NFS it is >> also cleared on MNT_NOATIME, but not on MNT_RDONLY. We need some sort >> of guideline in the documentation about what constitutes >> "unsupported": does atime become unsupported because filesystem is >> remounted r/o? If so, why isn't this case handled consistently in the >> VFS and filesystems? > > Strange. I'd think that if userspace is requesting atime, it should > get an atime value. The fact that the kernel is not updating atime > due to mount options just means that atime might be old. That doesn't > mean (IMHO) that atime doesn't exist. Right, OTOH I sort of see the value in NFS: no roundtrip to server if atime value is useless anyway. >> - What about fields that are not cached when statx() is called with >> AT_STATX_DONT_SYNC? E.g. stx_btime is supported by the filesystem, >> but getting it requires a roundtrip to the server. Requesting >> STATX_BTIME in the mask and adding AT_STATX_DONT_SYNC to the flags >> means the filesystem has to decide which it will honor. My feeling >> is that it should honor AT_STATX_DONT_SYNC and clear STATX_BTIME in >> stx_mask. Documentation has no word about this case. > > The btime value shouldn't change over the lifetime of a file, so > DONT_SYNC shouldn't have any effect on its validity? Not validity, but presence in the cache. Network filesystem or fuse may or may not have it available in the cache at the time the inode is first initialized on loookup. So when statx(..., AT_STATX_DONT_SYNC, STATX_BTIME) comes along, it may need a roundtrip to the server. What should it do? Thanks, Miklos