From: Chris Murphy <lists@colorremedies.com>
To: Henk Slager <eye1tm@gmail.com>
Cc: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
Martin Steigerwald <martin@lichtvoll.de>,
Imran Geriskovan <imran.geriskovan@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Small fs
Date: Mon, 12 Sep 2016 08:51:12 -0600 [thread overview]
Message-ID: <CAJCQCtTJChtn3hCwQKN0PHga07ze-tT0uJQf=dw3Woyv3-yjvg@mail.gmail.com> (raw)
In-Reply-To: <CAPmG0jZprQr8vnasD9E8hmadj3rYXvwkm9Ny6eCwqznbOGzDtA@mail.gmail.com>
On Mon, Sep 12, 2016 at 8:09 AM, Henk Slager <eye1tm@gmail.com> wrote:
>> FWIW, I use BTRFS for /boot, but it's not for snapshotting or even the COW,
>> it's for DUP mode and the error recovery it provides. Most people don't
>> think about this if it hasn't happened to them, but if you get a bad read
>> from /boot when loading the kernel or initrd, it can essentially nuke your
>> whole system. I run BTRFS for /boot in DUP mode with mixed-bg (because I
>> only use 512MB for boot) to mitigate the chance that a failed read has any
>> impact, and ensure that if it does, it will refuse to boot instead of
>> booting with a corrupted kernel or initrd.
>
> Suppose kernel and initrd are on a BTRFS fs with data, metadata and
> system all single profile. Will a bootloader then just continue
> booting up a system even when there are csum errors in kernel and/or
> initrd files? Suppose the bootloader is grub2.
I"m wondering the same thing. I don't know if GRUB's Btrfs code checks
for csum matches, and on error whether it knows to retry from some
other block group.
--
Chris Murphy
next prev parent reply other threads:[~2016-09-12 14:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-11 15:27 Small fs Imran Geriskovan
2016-09-11 15:32 ` Martin Steigerwald
2016-09-11 16:44 ` Duncan
2016-09-11 18:56 ` Imran Geriskovan
2016-09-11 19:21 ` Martin Steigerwald
2016-09-12 12:41 ` Austin S. Hemmelgarn
2016-09-12 14:09 ` Henk Slager
2016-09-12 14:12 ` Austin S. Hemmelgarn
2016-09-12 14:51 ` Chris Murphy [this message]
2016-09-12 14:56 ` Austin S. Hemmelgarn
2016-09-12 3:33 ` Duncan
2016-09-12 14:11 ` Imran Geriskovan
2016-09-12 17:43 ` Imran Geriskovan
2016-09-12 18:46 ` Imran Geriskovan
2016-09-12 18:55 ` Austin S. Hemmelgarn
2016-09-12 21:32 ` Mike Fleetwood
2016-09-11 19:13 ` Martin Steigerwald
2016-09-11 19:46 ` Hugo Mills
2016-09-11 19:51 ` Martin Steigerwald
2016-09-12 12:45 ` Austin S. Hemmelgarn
2016-09-11 20:33 ` Chris Murphy
2016-09-12 2:00 ` Duncan
2016-09-12 3:03 ` Chris Murphy
2016-09-12 4:54 ` Duncan
2016-09-12 14:48 ` Chris Murphy
2016-09-13 4:25 ` Duncan
2016-09-12 12:54 ` Imran Geriskovan
2016-09-12 13:01 ` Austin S. Hemmelgarn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJCQCtTJChtn3hCwQKN0PHga07ze-tT0uJQf=dw3Woyv3-yjvg@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=ahferroin7@gmail.com \
--cc=eye1tm@gmail.com \
--cc=imran.geriskovan@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=martin@lichtvoll.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).