From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs and integration with GNU ++
Date: Wed, 20 May 2015 14:04:00 -0400 [thread overview]
Message-ID: <20150520180400.GA15531@hungrycats.org> (raw)
In-Reply-To: <CAJCQCtSnM9hjCRGFBawOpEuvsOxyoB6vCwCVP5KFWwVqMD_g5g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]
On Tue, May 19, 2015 at 12:02:31PM -0600, Chris Murphy wrote:
> On Tue, May 19, 2015 at 1:24 AM, Russell Coker <russell@coker.com.au> wrote:
> > Do you have a reference for fsck on a ro mounted ext4 filesystem being dangerous? The standard behavior of Linux systems has been to fsck a ro mounted ext* root filesystem since long before an initrd was invented.
>
> Actually, slight confusion. XFS has a repair dangerously mode
> explicitly for repairing ro mounted XFS file systems. The man page for
> e2fsck says it's unsafe to fsck a mounted fs. It doesn't explicitly
> distinguish between ro and rw mounts, but from this list I've learned
> ro mounts aren't guaranteed to be ro, even if they should be ro. The
> e2fsck man page says even if it's safe, it's unreliable.
>
> Anyway, it seems worse to me to have a system where you have to ro
> mount a file system that you suspect might be inconsistent so that the
> fsck binary can be read and then operated on that same file system.
> Ancient madness.
The ancient method was to run fsck on a RO mounted root filesystem,
and if fsck corrected errors, immediately reboot to avoid corruption.
Hopefully the second boot gets past the root filesystem, which is
theoretically now clean. This fails badly if the fsck needs to touch
metadata required for the fsck or reboot, leading to failure of the
init scripts (there is no systemd in the ancient method) followed by
potentially massive root filesystem corruption. That sounds bad, but in
practical terms there were so many failure modes in the ancient method
that there's no point in choosing just one to get upset over. ;)
These days we have initramfs, which can treat the root filesystem like
any other filesystem, and check it fully offline before mounting it.
Put dropbear on the initramfs and the filesystem can be interactively
repaired over the network before mounting it too.
Alas, I don't know of any distros that handle root mounts correctly.
I always have to roll my own initramfs to get it right. >:-/
>
> --
> Chris Murphy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2015-05-20 18:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-17 19:33 Btrfs and integration with GNU ++ Roy Sigurd Karlsbakk
2015-05-18 1:32 ` Qu Wenruo
2015-05-18 6:41 ` Duncan
2015-05-18 8:57 ` Duncan
2015-05-18 9:22 ` Roy Sigurd Karlsbakk
2015-05-18 11:58 ` Austin S Hemmelgarn
2015-05-18 14:31 ` Chris Murphy
2015-05-19 17:09 ` Roy Sigurd Karlsbakk
2015-05-19 18:05 ` Chris Murphy
2015-05-19 18:09 ` Chris Murphy
2015-05-19 19:41 ` Eric Sandeen
2015-05-19 20:04 ` Chris Murphy
2015-05-20 6:45 ` Duncan
2015-05-18 14:24 ` Chris Murphy
2015-05-19 7:24 ` Russell Coker
2015-05-19 11:56 ` Austin S Hemmelgarn
2015-05-19 18:02 ` Chris Murphy
2015-05-20 18:04 ` Zygo Blaxell [this message]
2015-05-20 18:02 ` David Sterba
2015-05-18 15:14 ` Eric Sandeen
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=20150520180400.GA15531@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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).