From: Martin Steigerwald <martin@lichtvoll.de>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Christoph Anton Mitterer <calestyo@scientia.net>,
Duncan <1i5t5.duncan@cox.net>,
linux-btrfs@vger.kernel.org
Subject: Re: shall distros run btrfsck on boot?
Date: Wed, 25 Nov 2015 16:26:33 +0100 [thread overview]
Message-ID: <1946208.UO3P0Uc3S9@merkaba> (raw)
In-Reply-To: <5655AA62.2070901@gmail.com>
Am Mittwoch, 25. November 2015, 07:32:34 CET schrieb Austin S Hemmelgarn:
> On 2015-11-24 17:26, Eric Sandeen wrote:
> > On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:
> >> if the system was
> >> shut down cleanly, you're fine barring software bugs, but if it
> >> crashed, you should be running a check on the FS.
> >
> > Um, no...
> >
> > The *entire point* of having a journaling filesystem is that after a
> > crash or power loss, a journal replay on next mount will bring the
> > metadata into a consistent state.
>
> OK, first, that was in reference to BTRFS, not ext4, and BTRFS is a COW
> filesystem, not a journaling one, which is an important distinction as
> mentioned by Hugo in his reply. Second, there are two reasons that you
> should be running a check even of a journaled filesystem when the system
> crashes (this also applies to COW filesystems, and anything else that
> relies on atomicity of write operations for consistency):
>
> 1. Disks don't atomically write anything bigger than a sector, and may
> not even atomically write the sector itself. This means that it's
> possible to get a partial write to the journal, which in turn has
> significant potential to put the metadata in an inconsistent state when
> the journal gets replayed (IIRC, ext4 has a journal_checksum mount
> option that is supposed to mitigate this possibility). This sounds like
> something that shouldn't happen all that often, but on a busy
> filesystem, the probability is exactly proportionate to the size of the
> journal relative to the size of the FS.
>
> 2. If the system crashed, all code running on it immediately before the
> crash is instantly suspect, and you have no way to know for certain that
> something didn't cause random garbage to be written to the disk. On top
> of this, hardware is potentially suspect, and when your hardware is
> misbehaving, then all bets as to consistency are immediately off.
In the case of shaky hardware a fsck run can report bogus data, i.e. problems
where they are none or vice versa. If I suspect defect memory or controller I
would check the device on different hardware only. Especially on attempts to
repair any possible issues.
--
Martin
next prev parent reply other threads:[~2015-11-25 15:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 4:02 shall distros run btrfsck on boot? Christoph Anton Mitterer
2015-11-24 4:31 ` Wang Shilong
2015-11-24 4:35 ` Duncan
2015-11-24 4:40 ` Eric Sandeen
2015-11-24 4:43 ` Christoph Anton Mitterer
2015-11-24 5:33 ` Qu Wenruo
2015-11-24 6:46 ` Duncan
2015-11-24 6:56 ` Duncan
2015-11-24 17:14 ` Eric Sandeen
2015-11-24 17:23 ` Christoph Anton Mitterer
2015-11-24 20:38 ` Austin S Hemmelgarn
2015-11-24 22:26 ` Eric Sandeen
2015-11-24 22:33 ` Hugo Mills
2015-11-24 23:01 ` Christoph Anton Mitterer
2015-11-24 23:06 ` Hugo Mills
2015-11-25 1:59 ` shall distros run btrfsck on boot?(Off topic, btrfs per-inode tree idea) Qu Wenruo
2015-11-25 12:32 ` shall distros run btrfsck on boot? Austin S Hemmelgarn
2015-11-25 15:26 ` Martin Steigerwald [this message]
2015-11-28 16:52 ` Jeff Mahoney
2015-11-30 1:59 ` Qu Wenruo
2015-11-30 19:27 ` Jeff Mahoney
2015-11-30 15:06 ` 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=1946208.UO3P0Uc3S9@merkaba \
--to=martin@lichtvoll.de \
--cc=1i5t5.duncan@cox.net \
--cc=ahferroin7@gmail.com \
--cc=calestyo@scientia.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@redhat.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