From: Hugo Mills <hugo@carfax.org.uk>
To: Russell Coker <russell@coker.com.au>
Cc: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs hangs 3.19-10
Date: Sun, 5 Apr 2015 10:04:17 +0000 [thread overview]
Message-ID: <20150405100417.GE13864@carfax.org.uk> (raw)
In-Reply-To: <201504050330.47299.russell@coker.com.au>
[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]
On Sun, Apr 05, 2015 at 03:30:47AM +0000, Russell Coker wrote:
> On Sun, 5 Apr 2015 03:16:21 AM Duncan wrote:
> > Hugo Mills posted on Sat, 04 Apr 2015 13:00:47 +0000 as excerpted:
> > > On Sat, Apr 04, 2015 at 12:55:08PM +0000, Russell Coker wrote:
> > >> As an aside are there options to mkfs.btrfs that would make a
> > >> filesystem mountable by kernel 3.2.65? If so I'll file a Debian/Jessie
> > >> bug report requesting that a specific mention be added to the man page.
> > >
> > > Yes, there are. It's probably -O^extref, but if you can show the
> > > dmesg output from the 3.2 kernel on the failed mount (so that it shows
> > > what the actual failure was), we should be able to give you a more
> > > precise answer.
>
> [698190.987065] Btrfs loaded
> [698190.999992] device fsid 118e2c64-6ce1-4f21-85e2-2d6aea8f0fa5 devid 1
> transid 426 /dev/sdf1
> [698191.000981] btrfs: disk space caching is enabled
> [698191.000986] BTRFS: couldn't mount because of unsupported optional features
> (60).
That's these, I think:
#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA (1ULL << 5)
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF (1ULL << 6)
so it's definitely -O^extref. I don't see where big_metadata comes
from, though. That's not a -O option. Try with -O^extref and see where
that gets you. (Also, don't mount the FS on a newer kernel -- it may
be setting big metadata automatically, although it probably shouldn't
do).
Hugo.
> [698191.018176] btrfs: open_ctree failed
>
> > So I was thinking about this, and the several other earlier options where
> > support wasn't added until kernel X, and had an idea...
> >
> > How easy and useful might it be to add to mkfs.btrfs appropriate option-
> > group aliases such that if one knew the oldest kernel one was likely to
> > deal with, all one would need to do for the mkfs would be to set for
> > example, -O3.2, or even simply --3.2 (or maybe even --32), and have
> > mkfs.btrfs automatically set/unset the appropriate options so it would
> > "just work" with that kernel and anything newer?
>
> That would be really useful. Also it would be good if the code structure
> allowed adding extra aliases, so for Debian we could add an option -Owheezy.
>
--
Hugo Mills | Nostalgia isn't what it used to be.
hugo@... carfax.org.uk |
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2015-04-05 10:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 11:38 Btrfs hangs 3.19-10 Timofey Titovets
2015-04-02 11:46 ` Hugo Mills
2015-04-02 11:47 ` Timofey Titovets
2015-04-02 14:13 ` Roman Mamedov
2015-04-03 5:14 ` Duncan
2015-04-04 12:55 ` Russell Coker
2015-04-04 13:00 ` Hugo Mills
2015-04-05 3:16 ` Duncan
2015-04-05 3:30 ` Russell Coker
2015-04-05 10:04 ` Hugo Mills [this message]
2015-04-06 3:21 ` Duncan
2015-04-06 8:39 ` Russell Coker
2015-04-06 7:40 ` Pavel Volkov
2015-04-06 8:37 ` Russell Coker
2015-04-06 9:20 ` Duncan
2015-04-06 9:29 ` Duncan
2015-04-06 10:13 ` Hugo Mills
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=20150405100417.GE13864@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=russell@coker.com.au \
/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