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
next prev parent 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).