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=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, 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 AE499C432C3 for ; Wed, 13 Nov 2019 17:00:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4CD24206D5 for ; Wed, 13 Nov 2019 17:00:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=colorremedies-com.20150623.gappssmtp.com header.i=@colorremedies-com.20150623.gappssmtp.com header.b="aIflILki" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728517AbfKMRA5 (ORCPT ); Wed, 13 Nov 2019 12:00:57 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:40532 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727254AbfKMRA5 (ORCPT ); Wed, 13 Nov 2019 12:00:57 -0500 Received: by mail-wm1-f67.google.com with SMTP id f3so2834785wmc.5 for ; Wed, 13 Nov 2019 09:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorremedies-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c8MsDOx+XnNsG9QFCinxJLPBgZ2/bxXvS8asLAnc2bA=; b=aIflILkieoF//tBWfejneAI5mdrJjtouv6yObDla3JYmtPEfrEG2HcZYI37XU4wUzs Aixy6+pgacpKVzmoIv614/BgjikzB4YuXXQkKWIPjQTjNQwcwtiSr97+ACjKaXQAWrVA 1U2XkDsqe5mjhubFsT/I3XLcGtkCK8w6Fmwd53SwBUV6DDVOCZ1NHDEkOIHFDc0QXZ25 1VF2Z3eHzGGXUFlh40+SvrD4+IRDrh6lFJhNNydr3FOBXFUleFOUKfen+BbPzFreqNbm Xx6VvGfcBTo7a8QlHL+1vr1/5SZUBGIxnHJnWyNw3c9NjsmdhkML0TKdUbQWlhTkc0hO DlPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c8MsDOx+XnNsG9QFCinxJLPBgZ2/bxXvS8asLAnc2bA=; b=bc1Fy2L6JyzGZ6WmnZAelmFd3BSIorJioyuEUwy51zBTz/o3ad2CFpvFgwWMW+qayE R/qSSE1cyuKf/SL5bohPDuM8vZok+M/6EvRRYXmiDP1HTI4Dgtw6RzPypUcUAO1NLJmZ 7b7uDrOnsX0mMf3XsFUpU1WPnCakz3knml16nUx/sBwBmt5QoV1HY6YJ5dZy5ImJFnOD L9OsnA+cQtC5RK+KlB02aA4gXfjamWGmEGTyuyU0D4bIAx3RjsPtsAOuWr81UeXkKiu5 Y+tlVmVpXPX3PQk/AjIr0c4wooJ7Td5AwAwPcukZUEQTL2leGwBQc4YCwicwquW2jz/O +70Q== X-Gm-Message-State: APjAAAVa1xmI4pBo2EvO2cT3n+LHHHo+IKtyJ0Wk7FeLBJ8eixl4GOsN ye3gtjpBedE/X431WeptzcLES1u7Ci4Lw83u6R7ERg== X-Google-Smtp-Source: APXvYqzEwMdsyjHyvG7+hJ41l6/MqSuSAcTQ7h1yEDcMxGdt3vxhBFYyMK5tLiNLTJZU7nOQ1+z4MDyxpBQIeK3X3sM= X-Received: by 2002:a7b:cb4a:: with SMTP id v10mr3536436wmj.106.1573664455972; Wed, 13 Nov 2019 09:00:55 -0800 (PST) MIME-Version: 1.0 References: <20191104193454.GD3001@twin.jikos.cz> In-Reply-To: From: Chris Murphy Date: Wed, 13 Nov 2019 17:00:20 +0000 Message-ID: Subject: Re: Does GRUB btrfs support log tree? To: Goffredo Baroncelli Cc: Chris Murphy , David Sterba , Andrei Borzenkov , Btrfs BTRFS Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Tue, Nov 12, 2019 at 8:04 PM Goffredo Baroncelli wrote: > > On 11/11/2019 20.37, Chris Murphy wrote: > > Anyway, the lack of a generic (file system independent) way to handle > > this use case is actually a bit concerning. > > I think that a more simpler approach would be developing a GRUB fs, where is the kernel to be adapted to the needing of GRUB... > So we can lowering the requirement... I do really agree with this. It seems like a neat idea that a bootloader can just read any file system, but when it cannot have a true/complete view of the file system state because it just flat out ignores critical parts of the file system? Egads. > The GRUB-fs should have the following main requirements: > - allow the atomicity guarantee > - allow molti-disk setup > - allow grub to update some file (grubenv come me as first) > - it should require a simple implementation (easy to porting to multiple system, which basically means linux, *bsd and solaris ?) > - the speed should be not important Plausibly we're most of the way there already, adapting the existing "BIOS Boot" partition. > > > Anyway GRUB on BTRFS suffers of a big limitation: GRUB can't update the grubenv file; and until GRUB will learn how update a COW filesystem, this limit will be impossible to avoid (*) Yep. And I've discussed it with XFS and ext4 devs and they're not keen on anything writing into file system space outside of their (kernel or user space repair too) code, which is a reasonable concern. XFS doesn't have inline extents yet, but it's proposed. ext4 does have inline extents I think but not enabled by default, and I also think it takes a non-default inode size to support the ~1KiB typical grubenv file size: but inline extents would be subject to metadata checksumming, same as on Btrfs. So in effect, there are valid use cases that are, or may soon become, invalid for grubenv use as currently implemented, on the most common Linux file systems. > (*) Even tough implementing the update of a NOCSUM file should be not so difficult... So far I've seen 1KiB grubenv is pretty much always an inline extent on Btrfs. Even if flagged nocow it ends up being subject to leaf checksum. If GRUB modifies this grubenv, now that whole leaf is invalid which could mean data loss for things not even related to the grubenv, depending on what else is in the leaf. I mean, GRUB is very cool in many ways, but it's so complicated that maintaining it all I think is a real challenge and concern. And then on top of that, the various distributions actively fork it into their own mutually incompatible flavors. It's like GRUB is a set of LEGOs and everyone can really optionally build their own whatever. -- Chris Murphy