Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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

  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