linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>,
	Anatoly Pugachev <matorola@gmail.com>
Subject: Re: [PATCH v2 3/6] Btrfs: catch invalid free space trees
Date: Thu, 29 Sep 2016 13:43:40 +0200	[thread overview]
Message-ID: <20160929114340.GA5531@twin.jikos.cz> (raw)
In-Reply-To: <20160926231329.GA23991@vader.DHCP.thefacebook.com>

On Mon, Sep 26, 2016 at 04:13:29PM -0700, Omar Sandoval wrote:
> > +/*
> > + * Older kernels on big-endian systems produced broken free space tree bitmaps,
> > + * and btrfs-progs also used to corrupt the free space tree. If this bit is
> > + * clear, then the free space tree cannot be trusted. btrfs-progs can also
> > + * intentionally clear this bit to ask the kernel to rebuild the free space
> > + * tree.
> > + */
> 
> Hm, I think I changed my mind about allowing btrfs-progs to clear the
> bit intentionally. This creates a problem where we have a valid free
> space tree, modify it with btrfs-progs and clear the bit, and then mount
> it on an older kernel that doesn't check for the valid bit. If we really
> wanted to, we could add yet another bit, say, FREE_SPACE_TREE_INVALID,
> which prevents old kernels from mounting it, but I don't want to add
> more hacks just because write support hasn't been implemented in progs
> yet. That doesn't change this patch at all except for the comment here.

What you describe is possible to happen but still rare, the lowest
recommended kernel for general FST feature use will be at least 4.9. We
can describe the buggy kernel/tools combinations and recommended stafety
steps, like clearing the cache manually etc.

> Should I resend it or can this be fixed on applying?

I can update the wording.

  reply	other threads:[~2016-09-29 11:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23  0:22 [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes Omar Sandoval
2016-09-23  0:24 ` [PATCH v2 1/6] Btrfs: fix free space tree bitmaps on big-endian systems Omar Sandoval
2016-09-23 14:37   ` Holger Hoffstätte
2016-09-23  0:24 ` [PATCH v2 2/6] Btrfs: fix mount -o clear_cache,space_cache=v2 Omar Sandoval
2016-09-23 14:37   ` Holger Hoffstätte
2016-09-23  0:24 ` [PATCH v2 3/6] Btrfs: catch invalid free space trees Omar Sandoval
2016-09-23 14:40   ` Holger Hoffstätte
2016-09-24 19:50   ` Hans van Kranenburg
2016-09-26 17:39     ` Omar Sandoval
2016-09-26 17:46       ` Hans van Kranenburg
2016-09-26 17:52         ` Omar Sandoval
2016-09-26 23:13   ` Omar Sandoval
2016-09-29 11:43     ` David Sterba [this message]
2016-09-23  0:24 ` [PATCH v2 4/6] Btrfs: fix extent buffer bitmap tests on big-endian systems Omar Sandoval
2016-09-23  0:24 ` [PATCH v2 5/6] Btrfs: expand free space tree sanity tests to catch endianness bug Omar Sandoval
2016-09-23  0:24 ` [PATCH v2 6/6] Btrfs: use less memory for delalloc sanity tests Omar Sandoval
2016-09-23  9:27   ` David Sterba
2016-09-23 16:52     ` Omar Sandoval
2016-09-23 21:22       ` Omar Sandoval
2016-09-26 15:58         ` David Sterba
2016-09-26 17:33           ` Omar Sandoval
2016-09-25  7:55 ` [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes Anatoly Pugachev
2016-09-26 17:50   ` David Sterba
2016-09-26 17:56     ` Omar Sandoval
2016-09-29 12:21     ` Anatoly Pugachev
2016-09-29 12:52       ` Holger Hoffstätte
2016-09-29 13:02         ` Anatoly Pugachev
2016-09-29 14:29           ` David Sterba
2016-10-01  9:26             ` Anatoly Pugachev
2016-09-26 17:51   ` Omar Sandoval
2016-09-28 13:03 ` Chandan Rajendra

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=20160929114340.GA5531@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=matorola@gmail.com \
    --cc=osandov@osandov.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).