Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Pavel Volkov <sailor@lists.xtsubasa.org>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs hangs 3.19-10
Date: Mon, 6 Apr 2015 08:37:33 +0000	[thread overview]
Message-ID: <201504060837.33776.russell@coker.com.au> (raw)
In-Reply-To: <2f6a9ac9-0684-4b9a-982e-031286be398e@lists.xtsubasa.org>

On Mon, 6 Apr 2015 07:40:03 AM Pavel Volkov wrote:
> On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
> >    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).
> 
> By the way, is there any way to see which options are enabled on a local
> filesystem without having to try mounting it with old kernel and checking
> dmesg?

# file -s /dev/dm-0 
/dev/dm-0: BTRFS Filesystem sectorsize 4096, nodesize 4096, leafsize 4096, 
UUID=97d70558-ddea-493e-874c-ff74be9ce099, 92390113280/171796594688 bytes used, 
1 devices

Above is what file(1) reports on my laptop which has been running BTRFS since 
3.2 days.  It gives the node size etc but not the feature flags.  Some time ago 
I submitted a patch to the Debian package that covered everything I could 
figure out, I'm sure that they would accept a patch for feature flags if anyone 
can work out how to do it.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

  reply	other threads:[~2015-04-06  8:37 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
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 [this message]
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=201504060837.33776.russell@coker.com.au \
    --to=russell@coker.com.au \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sailor@lists.xtsubasa.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