linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Anatoly Pugachev <matorola@gmail.com>
Cc: Chris Mason <clm@fb.com>,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	kernel-team@fb.com, sparclinux@vger.kernel.org
Subject: Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems
Date: Fri, 26 Aug 2016 17:56:56 -0700	[thread overview]
Message-ID: <20160827005656.GA8439@vader.DHCP.thefacebook.com> (raw)
In-Reply-To: <CADxRZqwHPVTdiKQa89Y0gbBWS-UMWwYzqLSnBNRhx9U33iSdKw@mail.gmail.com>

On Fri, Aug 26, 2016 at 02:06:29PM +0300, Anatoly Pugachev wrote:
> On Thu, Aug 18, 2016 at 11:33 PM, Omar Sandoval <osandov@osandov.com> wrote:
> > On Tue, Jul 19, 2016 at 03:25:16PM -0400, Chris Mason wrote:
> >> On 07/19/2016 12:06 PM, Chandan Rajendra wrote:
> >>
> >> Omar, looks like we need to make the patched kernel refuse to mount free
> >> space trees without a new incompat bit set.  That way there won't be any
> >> surprises for the people that have managed to get a free space tree saved.
> >> Can it please printk a message about clearing the tree and mounting again?
> >>
> > Sorry it took me a month to get around to this, I tried to implement
> > this a couple of ways but I really don't like it. Basically, when we see
> > that we're missing the compat bit, we have to assume that the free space
> > tree was created with the same endianness that we're running on now.
> > That could lead to a false positive if, say, we created the filesystem
> > on a little-endian machine with an old kernel but are using it on a
> > big-endian system, or a false negative if it was created on a big-endian
> > machine with an old kernel but we're using it on a little-endian
> > machine.
> >
> > There's also the question of making it a compat bit vs an incompat bit.
> > An incompat bit makes sure that we don't break the filesystem by
> > mounting it on an old big-endian kernel, but needlessly breaks
> > backwards-compatibility for little-endian.
> >
> > I'd be much happier if we could just pretend this never happened. Here's
> > the patch, anyways, for the sake of completeness. Chris, what do you
> > think?
> 
> Omar,
> 
> I can't load btrfs module with this patch applied to 4.8.0-rc3+ (git
> v4.8-rc3-39-g61c0457)
> on "modprobe btrfs" i'm getting the following in the logs and module
> does not load:
> 
> Btrfs loaded, crc32c=crc32c-generic, debug=on, assert=on
> BTRFS: selftest: sectorsize: 8192  nodesize: 8192
> BTRFS: selftest: Running btrfs free space cache tests
> BTRFS: selftest: Running extent only tests
> BTRFS: selftest: Running bitmap only tests
> BTRFS: selftest: Running bitmap and extent tests
> BTRFS: selftest: Running space stealing from bitmap to extent
> BTRFS: selftest: Free space cache tests finished
> BTRFS: selftest: Running extent buffer operation tests
> BTRFS: selftest: Running btrfs_split_item tests
> BTRFS: selftest: Running extent I/O tests
> BTRFS: selftest: Running find delalloc tests
> BTRFS: selftest: Running extent buffer bitmap tests
> BTRFS: selftest: Setting straddling pages failed
> BTRFS: selftest: Extent I/O tests finished

Is this with the whole patchset + this patch? You still need the patch
set for this to actually work, the extra patch is just some extra
checks.

-- 
Omar

  reply	other threads:[~2016-08-27  0:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14 23:31 [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems Omar Sandoval
2016-07-14 23:31 ` [PATCH 1/3] Btrfs: fix free space tree bitmaps " Omar Sandoval
2016-07-14 23:31 ` [PATCH 2/3] Btrfs: fix extent buffer bitmap tests " Omar Sandoval
2016-07-14 23:31 ` [PATCH 3/3] Btrfs: expand free space tree sanity tests to catch endianness bug Omar Sandoval
2016-07-14 23:47 ` [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems Chris Mason
2016-07-15  7:04   ` Chandan Rajendra
2016-07-15 19:15     ` Omar Sandoval
2016-07-17 12:19       ` Chandan Rajendra
2016-07-18 18:43         ` Chris Mason
2016-07-18 22:31           ` Omar Sandoval
2016-07-19 16:06             ` Chandan Rajendra
2016-07-19 19:25               ` Chris Mason
2016-08-18 20:33                 ` Omar Sandoval
2016-08-26 11:06                   ` Anatoly Pugachev
2016-08-27  0:56                     ` Omar Sandoval [this message]
2016-08-27  7:16                       ` Anatoly Pugachev
2016-09-21 14:50                   ` David Sterba
2016-09-21 17:35                     ` Omar Sandoval
2016-07-31 13:04 ` Anatoly Pugachev

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=20160827005656.GA8439@vader.DHCP.thefacebook.com \
    --to=osandov@osandov.com \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=clm@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=matorola@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    /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).