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.2 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 6BAAFCA9EB5 for ; Mon, 4 Nov 2019 19:34:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 491D22080F for ; Mon, 4 Nov 2019 19:34:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729199AbfKDTet (ORCPT ); Mon, 4 Nov 2019 14:34:49 -0500 Received: from mx2.suse.de ([195.135.220.15]:44308 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728654AbfKDTes (ORCPT ); Mon, 4 Nov 2019 14:34:48 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3C70FABE9; Mon, 4 Nov 2019 19:34:47 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 98762DB6FC; Mon, 4 Nov 2019 20:34:54 +0100 (CET) Date: Mon, 4 Nov 2019 20:34:54 +0100 From: David Sterba To: Chris Murphy Cc: Andrei Borzenkov , Btrfs BTRFS Subject: Re: Does GRUB btrfs support log tree? Message-ID: <20191104193454.GD3001@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Chris Murphy , Andrei Borzenkov , Btrfs BTRFS References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sun, Oct 27, 2019 at 09:05:54PM +0100, Chris Murphy wrote: > > > Since log tree writes means a > > > full file system update hasn't happened, the old file system state > > > hasn't been dereferenced, so even in an SSD + discard case, the system > > > should still be bootable. And at that point Btrfs kernel code does log > > > replay, and catches the system up, and the next update will boot the > > > new state. > > > > > > Correct? > > > > > > > Yes. If we speak about grub here, it actually tries very hard to ensure > > writes has hit disk (it fsyncs files as it writes them and it flushes > > raw devices). But I guess that fsync on btrfs just goes into log and > > does not force transaction. Is it possible to force transaction on btrfs > > from user space? * sync/syncfs * the ioctl BTRFS_IOC_SYNC (calls syncfs) * ioctls BTRFS_IOC_START_SYNC + BTRFS_IOC_WAIT_SYNC > The only fsync I ever see Fedora's grub2-mkconfig do is for grubenv. > The grub.cfg is not fsync'd. When I do a strace of grub2-mkconfig, > it's so incredibly complicated. Using -ff -o options, I get over 1800 > separate PID files exported. From what I can tell, it creates a brand > new file "grub.cfg.new" and writes to that. Then does a cat from > "grub.cfg.new" into "grub.cfg" - maybe it's file system specific > behavior, I'm not sure. > > I'm pretty sure "sync" will do what you want, it calls syncfs() and > best as I can tell it does a full file system sync, doesn't use the > log tree. I'd argue grub-mkconfig should write all of its files, and > then sync that file system, rather than doing any fsync at all. This would work in most cases. I'm not sure, but the update does not seem to be atomic. Ie. all old kernels match the old grub.cfg, or there are new kernels that match the new cfg. Even if there's not fsyncs and just the final sync, some other activity in the filesystem can do the sync before between updates of kernels and grub.cfg. Like this start: - kernel1 - grub.cfg (v1) update: - add kernel2 - remove kernel1 - - update grub.cfg (v2) - grub calls sync If the crash happens after sync and before update, kernel1 won't be reachable and kernel2 won't be in the grub.cfg.