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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 5CB7CC433E6 for ; Tue, 12 Jan 2021 05:22:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2980622CA2 for ; Tue, 12 Jan 2021 05:22:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388394AbhALFV6 (ORCPT ); Tue, 12 Jan 2021 00:21:58 -0500 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:44302 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725554AbhALFV6 (ORCPT ); Tue, 12 Jan 2021 00:21:58 -0500 Received: from dread.disaster.area (pa49-179-167-107.pa.nsw.optusnet.com.au [49.179.167.107]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 8C2BE826077; Tue, 12 Jan 2021 16:21:15 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1kzC7G-005aGL-IW; Tue, 12 Jan 2021 16:21:14 +1100 Date: Tue, 12 Jan 2021 16:21:14 +1100 From: Dave Chinner To: Eric Biggers Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Theodore Ts'o Subject: Re: [PATCH v2 04/12] fat: only specify I_DIRTY_TIME when needed in fat_update_time() Message-ID: <20210112052114.GS331610@dread.disaster.area> References: <20210109075903.208222-1-ebiggers@kernel.org> <20210109075903.208222-5-ebiggers@kernel.org> <20210111105201.GB2502@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=Ubgvt5aN c=1 sm=1 tr=0 cx=a_idp_d a=+wqVUQIkAh0lLYI+QRsciw==:117 a=+wqVUQIkAh0lLYI+QRsciw==:17 a=kj9zAlcOel0A:10 a=EmqxpYm9HcoA:10 a=7-415B0cAAAA:8 a=joOgMYZwUYIHNJ8tGMoA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Jan 11, 2021 at 11:50:27AM -0800, Eric Biggers wrote: > On Mon, Jan 11, 2021 at 11:52:01AM +0100, Christoph Hellwig wrote: > > On Fri, Jan 08, 2021 at 11:58:55PM -0800, Eric Biggers wrote: > > > + if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > > + dirty_flags |= I_DIRTY_SYNC; > > > > fat does not support i_version updates, so this bit can be skipped. > > Is that really the case? Any filesystem (including fat) can be mounted with > "iversion", which causes SB_I_VERSION to be set. That's a bug. Filesystems taht don't support persistent i_version on disk need to clear SB_I_VERSION in their mount and remount paths because the VFS iversion mount option was a complete screwup from the start. > A lot of filesystems (including fat) don't store i_version to disk, but it looks > like it will still get updated in-memory. Could anything be relying on that? If they do, then they are broken by definition. i_version as reported to observers is defined as monotonically increasing with every change to the inode. i.e. it never goes backwards. Which, of course, it will do if you crash or even just unmount/mount a filesystem that doesn't persist it. Cheers, Dave. -- Dave Chinner david@fromorbit.com 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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 AC250C433DB for ; Tue, 12 Jan 2021 05:42:36 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 53EBC22CB2; Tue, 12 Jan 2021 05:42:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53EBC22CB2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kzCRu-0007LF-Ku; Tue, 12 Jan 2021 05:42:34 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzCRt-0007Kz-3m for linux-f2fs-devel@lists.sourceforge.net; Tue, 12 Jan 2021 05:42:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CGAqWqlaxWjocJQqXZ6l5IvsBY8vVAuCi4hJf+54fOQ=; b=BwLf0hPNhrr3oB2hqlryGGa5Bv yJeO0N3gCWzBKTEnPjTTtmBjvx2m8eJIuOKrf39SEblOTPCDoD0EckhYPOOu+5rTMMU6LBc5FQ7x2 FfuPIjf/K1wozPNg1QCqkRAvw7PK2RIJNcHVEc7Z+ldVmHun/IMOggCLrCiwQKr517Ks=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CGAqWqlaxWjocJQqXZ6l5IvsBY8vVAuCi4hJf+54fOQ=; b=NalsSJujKTOcNEUFYYUBWb9ujO JzBot6Q4a2LIz4medYk1zAKp8PHkTXQnHZXSTNZ3tDDLtZrFZjhzxIR40GBS6ECoZksZWSCX4qjTa NbdSdW8zNSBG7SXUxhQOJqiBbKkOz70kf/ymU056OTiULN9BYrrT32hO2p+PoFVgaEMo=; Received: from mail104.syd.optusnet.com.au ([211.29.132.246]) by sfi-mx-3.v28.lw.sourceforge.com with esmtp (Exim 4.92.2) id 1kzCRg-002seT-Rj for linux-f2fs-devel@lists.sourceforge.net; Tue, 12 Jan 2021 05:42:33 +0000 Received: from dread.disaster.area (pa49-179-167-107.pa.nsw.optusnet.com.au [49.179.167.107]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 8C2BE826077; Tue, 12 Jan 2021 16:21:15 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1kzC7G-005aGL-IW; Tue, 12 Jan 2021 16:21:14 +1100 Date: Tue, 12 Jan 2021 16:21:14 +1100 From: Dave Chinner To: Eric Biggers Message-ID: <20210112052114.GS331610@dread.disaster.area> References: <20210109075903.208222-1-ebiggers@kernel.org> <20210109075903.208222-5-ebiggers@kernel.org> <20210111105201.GB2502@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=Ubgvt5aN c=1 sm=1 tr=0 cx=a_idp_d a=+wqVUQIkAh0lLYI+QRsciw==:117 a=+wqVUQIkAh0lLYI+QRsciw==:17 a=kj9zAlcOel0A:10 a=EmqxpYm9HcoA:10 a=7-415B0cAAAA:8 a=joOgMYZwUYIHNJ8tGMoA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 X-Headers-End: 1kzCRg-002seT-Rj Subject: Re: [f2fs-dev] [PATCH v2 04/12] fat: only specify I_DIRTY_TIME when needed in fat_update_time() X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Theodore Ts'o , linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Christoph Hellwig Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Mon, Jan 11, 2021 at 11:50:27AM -0800, Eric Biggers wrote: > On Mon, Jan 11, 2021 at 11:52:01AM +0100, Christoph Hellwig wrote: > > On Fri, Jan 08, 2021 at 11:58:55PM -0800, Eric Biggers wrote: > > > + if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) > > > + dirty_flags |= I_DIRTY_SYNC; > > > > fat does not support i_version updates, so this bit can be skipped. > > Is that really the case? Any filesystem (including fat) can be mounted with > "iversion", which causes SB_I_VERSION to be set. That's a bug. Filesystems taht don't support persistent i_version on disk need to clear SB_I_VERSION in their mount and remount paths because the VFS iversion mount option was a complete screwup from the start. > A lot of filesystems (including fat) don't store i_version to disk, but it looks > like it will still get updated in-memory. Could anything be relying on that? If they do, then they are broken by definition. i_version as reported to observers is defined as monotonically increasing with every change to the inode. i.e. it never goes backwards. Which, of course, it will do if you crash or even just unmount/mount a filesystem that doesn't persist it. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel