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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21EA0C6FA8D for ; Mon, 12 Sep 2022 14:51:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230224AbiILOvB (ORCPT ); Mon, 12 Sep 2022 10:51:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229702AbiILOu7 (ORCPT ); Mon, 12 Sep 2022 10:50:59 -0400 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B47A33A13; Mon, 12 Sep 2022 07:50:58 -0700 (PDT) Received: by fieldses.org (Postfix, from userid 2815) id BA232607F; Mon, 12 Sep 2022 10:50:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org BA232607F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1662994257; bh=VDdSkcB3ak4apclVt/05byVDTIM05k6XxyMCdrwmp68=; h=Date:To:Cc:Subject:References:In-Reply-To:From:From; b=ZxaPJSMlBqmONwwNp0emyvFwmdCV+rXkOxnX0QmNvsUqYJ7+nv0vtXBhzTfFolKHm 8Z4pmf/VYv2EQvLqi0tre+x4AC6HjpEkOV3yYDAwkEgUFVH4VeM3qN5geCJuc/Oyte 4hAXnRcuTFvpSfnwUcfrGO2AyAk6TWRvxbXytk8k= Date: Mon, 12 Sep 2022 10:50:57 -0400 To: Trond Myklebust Cc: "jlayton@kernel.org" , "zohar@linux.ibm.com" , "djwong@kernel.org" , "xiubli@redhat.com" , "brauner@kernel.org" , "neilb@suse.de" , "linux-api@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "david@fromorbit.com" , "fweimer@redhat.com" , "linux-kernel@vger.kernel.org" , "chuck.lever@oracle.com" , "linux-man@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "tytso@mit.edu" , "viro@zeniv.linux.org.uk" , "jack@suse.cz" , "linux-ext4@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "adilger.kernel@dilger.ca" , "lczerner@redhat.com" , "ceph-devel@vger.kernel.org" Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new STATX_INO_VERSION field Message-ID: <20220912145057.GE9304@fieldses.org> References: <20220908182252.GA18939@fieldses.org> <44efe219dbf511492b21a653905448d43d0f3363.camel@kernel.org> <20220909154506.GB5674@fieldses.org> <125df688dbebaf06478b0911e76e228e910b04b3.camel@kernel.org> <20220910145600.GA347@fieldses.org> <9eaed9a47d1aef11fee95f0079e302bc776bc7ff.camel@kernel.org> <87a67423la.fsf@oldenburg.str.redhat.com> <7c71050e139a479e08ab7cf95e9e47da19a30687.camel@kernel.org> <20220912135131.GC9304@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Mon, Sep 12, 2022 at 02:15:16PM +0000, Trond Myklebust wrote: > On Mon, 2022-09-12 at 09:51 -0400, J. Bruce Fields wrote: > > On Mon, Sep 12, 2022 at 08:55:04AM -0400, Jeff Layton wrote: > > > Because of the "seen" flag, we have a 63 bit counter to play with. > > > Could > > > we use a similar scheme to the one we use to handle when "jiffies" > > > wraps? Assume that we'd never compare two values that were more > > > than > > > 2^62 apart? We could add i_version_before/i_version_after macros to > > > make > > > it simple to handle this. > > > > As far as I recall the protocol just assumes it can never wrap.  I > > guess > > you could add a new change_attr_type that works the way you describe. > > But without some new protocol clients aren't going to know what to do > > with a change attribute that wraps. > > > > I think this just needs to be designed so that wrapping is impossible > > in > > any realistic scenario.  I feel like that's doable? > > > > If we feel we have to catch that case, the only 100% correct behavior > > would probably be to make the filesystem readonly. > > > > Which protocol? If you're talking about basic NFSv4, it doesn't assume > anything about the change attribute and wrapping. > > The NFSv4.2 protocol did introduce the optional attribute > 'change_attr_type' that tries to describe the change attribute > behaviour to the client. It tells you if the behaviour is monotonically > increasing, but doesn't say anything about the behaviour when the > attribute value overflows. > > That said, the Linux NFSv4.2 client, which uses that change_attr_type > attribute does deal with overflow by assuming standard uint64_t wrap > around rules. i.e. it assumes bit values > 63 are truncated, meaning > that the value obtained by incrementing (2^64-1) is 0. Yeah, it was the MONOTONIC_INCRE case I was thinking of. That's interesting, I didn't know the client did that. --b.