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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 83A1DC10F14 for ; Tue, 15 Oct 2019 13:18:45 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 F2CCF21848 for ; Tue, 15 Oct 2019 13:18:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2CCF21848 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46swwv5FVzzDqmT for ; Wed, 16 Oct 2019 00:18:39 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=mit.edu X-Greylist: delayed 258 seconds by postgrey-1.36 at bilbo; Wed, 16 Oct 2019 00:14:46 AEDT Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46swrQ2ZggzDr3X for ; Wed, 16 Oct 2019 00:14:44 +1100 (AEDT) Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9FDA5N0018119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Oct 2019 09:10:06 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id CA393420287; Tue, 15 Oct 2019 09:10:04 -0400 (EDT) Date: Tue, 15 Oct 2019 09:10:04 -0400 From: "Theodore Y. Ts'o" To: Christoph Hellwig Subject: Re: [PATCH] xfs: introduce "metasync" api to sync metadata to fsblock Message-ID: <20191015131004.GA7456@mit.edu> References: <1570977420-3944-1-git-send-email-kernelfans@gmail.com> <20191013163417.GQ13108@magnolia> <20191014083315.GA10091@mypc> <20191014094311.GD5939@quack2.suse.cz> <20191014200303.GF5939@quack2.suse.cz> <5796090e-6206-1bd7-174e-58798c9af052@sandeen.net> <20191015080102.GB3055@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191015080102.GB3055@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jan Kara , Eric Sandeen , "Darrick J. Wong" , Jan Kara , Eric Sandeen , Pingfan Liu , linux-xfs@vger.kernel.org, Dave Chinner , linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Hari Bathini Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Oct 15, 2019 at 01:01:02AM -0700, Christoph Hellwig wrote: > On Mon, Oct 14, 2019 at 03:09:48PM -0500, Eric Sandeen wrote: > > We're in agreement here. ;) I only worry about implementing things like this > > which sound like guarantees, but aren't, and end up encouraging bad behavior > > or promoting misconceptions. > > > > More and more, I think we should reconsider Darrick's "bootfs" (ext2 by another > > name, but with extra-sync-iness) proposal... > > Having a separate simple file system for the boot loader makes a lot of > sense. Note that vfat of EFI is the best choice, but at least it is > something. SysV Unix from the 90s actually had a special file system just > for that, and fs/bfs/ in Linux supports that. So this isn't really a new > thing either. Did you mean to say "vfaat of EFI isn't the best choice"? If we were going to be doing something like "bootfs", what sort of semantics would be sufficient? Is doing an implied fsync() on every close(2) enough, or do we need to do something even more conservative? - Ted