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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 92F29C43219 for ; Fri, 3 May 2019 09:46:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6794F206DF for ; Fri, 3 May 2019 09:46:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726729AbfECJqP (ORCPT ); Fri, 3 May 2019 05:46:15 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:50435 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725777AbfECJqP (ORCPT ); Fri, 3 May 2019 05:46:15 -0400 Received: from callcc.thunk.org (adsl-173-228-226-134.prtc.net [173.228.226.134]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x439jhYI011160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 May 2019 05:45:46 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 5AD4D420024; Fri, 3 May 2019 05:45:43 -0400 (EDT) Date: Fri, 3 May 2019 05:45:43 -0400 From: "Theodore Ts'o" To: Vijay Chidambaram Cc: Amir Goldstein , lsf-pc@lists.linux-foundation.org, Dave Chinner , "Darrick J. Wong" , Jan Kara , linux-fsdevel , Jayashree Mohan , Filipe Manana , Chris Mason , lwn@lwn.net Subject: Re: [TOPIC] Extending the filesystem crash recovery guaranties contract Message-ID: <20190503094543.GD23724@mit.edu> References: <20190503023043.GB23724@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, May 02, 2019 at 10:15:01PM -0500, Vijay Chidambaram wrote: > > A few things to clarify: > 1) We are not suggesting that all file systems follow SOMC semantics. > If ext4 does not want to do so, we are quite happy to document ext4 > provides a different set of reasonable semantics. We can make the > ext4-related documentation as minimal as you want (or drop ext4 from > documentation entirely). I'm hoping this will satisfy you. > 2) As I understand it, I do not think SOMC rules out the scenario in > your example, because it does not require fsync to push un-related > files to storage. > 3) We are not documenting how fsync works internally, merely what the > user-visible behavior is. I think this will actually free up file > systems to optimize fsync aggressively while making sure they provide > the required user-visible behavior. As documented, the draft of the rules *I* saw specifically said that a fsync() to inode B would guarantee that metadata changes for inode A, which were made before the changes to inode B, would be persisted to disk since the metadata changes for B happened after the changes to inode A. It used the fsync(2) *explicitly* as an example for how ordering of unrelated files could be guaranteed. And this would invalidate Park and Shin's incremental journal for fsync. If the guarantees are when fsync(2) is *not* being used, sure, then the SOMC model is naturally what would happen with most common file system. But then fsync(2) needs to appear nowhere in the crash consistency model description, and that is not the case today. Best regards, - Ted