Re: Btrfs progs pre-release 4.3-rc1

[Chris Murphy]

On Mon, Nov 2, 2015 at 4:14 PM, David Sterba  wrote:
> Hi,
>
> the kernel 4.3 was released yesterday, the btrfs-progs will follow at the end
> of this week. I've tagged an rc1 from current devel branch. There are a lots 
> of
> small invisible changes and one change in the defaults:
>
> * mkfs: mixed mode is not forced anymore for devices smaller than 1 GiB

Why?

If it's still recommended to use mixed for small device, why not keep
it the default and just permit the user to manually specify something
else?


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mkfs.btrfs doesn't detect SSD

[Christoph Anton Mitterer]

Hey.

I'm creating a filesystem on Samsung Evo 850 Pro on top of a dm-
crypt/LUKS container (with TRIM not being passed on, for the usual
security reasons):
# mkfs.btrfs --label system /dev/mapper/system 
btrfs-progs v4.2.2
See http://btrfs.wiki.kernel.org for more information.

Label:  system
UUID:   65531196-2e43-4c49-b495-ac9abc57d7d8
Node size:  16384
Sector size:4096
Filesystem size:937.00GiB
Block group profiles:
  Data: single8.00MiB
  Metadata: DUP   1.01GiB
  System:   DUP  12.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   IDSIZE  PATH
1   937.00GiB  /dev/mapper/system


As you can see it doesn't detect the SSD.
Isn't that kinda problematic cause btrfs does more when it detects and
SSD than just using TRIM (e.g. not DUPing meta-data)?

Can I somehow override this to get the SSD "detected"?
Or what is the general suggestion here? Having it handled as SSD or as
non-SSD, as said, when dm-crypt is used below and TRIM is not intended
to be used.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] btrfs: qgroup: fix quota disable during rescan

[Filipe Manana]

On Fri, Nov 6, 2015 at 6:36 PM, Justin Maggard  wrote:
> There's a race condition that leads to a NULL pointer dereference if you
> disable quotas while a quota rescan is running.  To fix this, we just need
> to wait for the quota rescan worker to actually exit before tearing down
> the quota structures.
>
> Signed-off-by: Justin Maggard 

Justin, it looks good and it's a very good find.

But can you please give a more detailed change log? You mention a NULL
pointer dereference, but you don't say where, which variable nor why.
Pasting a trace of the crash you get in syslog/dmesg would also be
nice.

My guess is the null pointer dereference is in fs_info->quota_root,
but running the corresponding xfstest once I hit the
BUG_ON(!fs_info->quota_root) at btrfs_qgroup_account_extent(), called
by the rescan worker through qgroup_rescan_leaf().

Once you add that, you can add as well:  Reviewed-by: Filipe Manana


Thanks for this and the test.


> ---
>  fs/btrfs/qgroup.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
> index 75c0249..a7cf504 100644
> --- a/fs/btrfs/qgroup.c
> +++ b/fs/btrfs/qgroup.c
> @@ -993,9 +993,10 @@ int btrfs_quota_disable(struct btrfs_trans_handle *trans,
> mutex_lock(_info->qgroup_ioctl_lock);
> if (!fs_info->quota_root)
> goto out;
> -   spin_lock(_info->qgroup_lock);
> fs_info->quota_enabled = 0;
> fs_info->pending_quota_state = 0;
> +   btrfs_qgroup_wait_for_completion(fs_info);
> +   spin_lock(_info->qgroup_lock);
> quota_root = fs_info->quota_root;
> fs_info->quota_root = NULL;
> fs_info->qgroup_flags &= ~BTRFS_QGROUP_STATUS_FLAG_ON;
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] btrfs: test quota disable during quota rescan

[Filipe Manana]

On Fri, Nov 6, 2015 at 6:40 PM, Justin Maggard  wrote:
> This test case tests if we are able to disable quotas on a filesystem
> while a quota rescan is running.  Up to now (4.3) this would result
> in a kernel NULL pointer dereference.
>
> Fixed by patch (btrfs: qgroup: fix quota disable during rescan).
>
> Signed-off-by: Justin Maggard 
Reviewed-by: Filipe Manana 

Looks good and it triggers the bug without the btrfs kernel fix.

A side note, and if you would like you could do as a separate patch
imho, is to speedup creating the files by using multiple
jobs/processes (as we do in generic/038 for example) - the test takes
150 seconds on a debug kernel here, about 130 seconds were spent
creating the files. Same observation applies to your previous test
case as well.

Thanks for making this test.

> ---
>  tests/btrfs/115 | 62 
> +
>  tests/btrfs/115.out |  2 ++
>  tests/btrfs/group   |  1 +
>  3 files changed, 65 insertions(+)
>  create mode 100755 tests/btrfs/115
>  create mode 100644 tests/btrfs/115.out
>
> diff --git a/tests/btrfs/115 b/tests/btrfs/115
> new file mode 100755
> index 000..0d1cb3a
> --- /dev/null
> +++ b/tests/btrfs/115
> @@ -0,0 +1,62 @@
> +#! /bin/bash
> +# FS QA Test No. btrfs/115
> +#
> +# btrfs quota scan/disable sanity test
> +# Make sure that disabling quotas during a quota rescan doesn't crash
> +#
> +#---
> +# Copyright (c) 2015 NETGEAR, Inc.  All Rights Reserved.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it would be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write the Free Software Foundation,
> +# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> +#---
> +#
> +
> +seq=`basename $0`
> +seqres=$RESULT_DIR/$seq
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +tmp=/tmp/$$
> +status=1   # failure is the default!
> +trap "_cleanup; exit \$status" 0 1 2 3 15
> +
> +_cleanup()
> +{
> +   cd /
> +   rm -f $tmp.*
> +}
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +. ./common/filter
> +
> +# real QA test starts here
> +_supported_fs btrfs
> +_supported_os Linux
> +_require_scratch
> +
> +_scratch_mkfs >>$seqres.full 2>&1
> +_scratch_mount
> +
> +for i in `seq 0 1 45`; do
> +   echo -n > $SCRATCH_MNT/file.$i
> +done
> +echo 3 > /proc/sys/vm/drop_caches
> +$BTRFS_UTIL_PROG quota enable $SCRATCH_MNT
> +$BTRFS_UTIL_PROG quota disable $SCRATCH_MNT
> +
> +
> +echo "Silence is golden"
> +status=0
> +exit
> diff --git a/tests/btrfs/115.out b/tests/btrfs/115.out
> new file mode 100644
> index 000..d9dd136
> --- /dev/null
> +++ b/tests/btrfs/115.out
> @@ -0,0 +1,2 @@
> +QA output created by 115
> +Silence is golden
> diff --git a/tests/btrfs/group b/tests/btrfs/group
> index 10ab26b..39b9aff 100644
> --- a/tests/btrfs/group
> +++ b/tests/btrfs/group
> @@ -117,3 +117,4 @@
>  112 auto quick clone
>  113 auto quick compress clone
>  114 auto qgroup
> +115 auto qgroup
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mkfs.btrfs doesn't detect SSD

[Chris Murphy]

On Sat, Nov 7, 2015 at 4:05 PM, Christoph Anton Mitterer
 wrote:
> Hey.
>
> I'm creating a filesystem on Samsung Evo 850 Pro on top of a dm-
> crypt/LUKS container (with TRIM not being passed on, for the usual
> security reasons):
> # mkfs.btrfs --label system /dev/mapper/system
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
>
> Label:  system
> UUID:   65531196-2e43-4c49-b495-ac9abc57d7d8
> Node size:  16384
> Sector size:4096
> Filesystem size:937.00GiB
> Block group profiles:
>   Data: single8.00MiB
>   Metadata: DUP   1.01GiB
>   System:   DUP  12.00MiB
> SSD detected:   no
> Incompat features:  extref, skinny-metadata
> Number of devices:  1
> Devices:
>IDSIZE  PATH
> 1   937.00GiB  /dev/mapper/system
>
>
> As you can see it doesn't detect the SSD.
> Isn't that kinda problematic cause btrfs does more when it detects and
> SSD than just using TRIM (e.g. not DUPing meta-data)?
>
> Can I somehow override this to get the SSD "detected"?
> Or what is the general suggestion here? Having it handled as SSD or as
> non-SSD, as said, when dm-crypt is used below and TRIM is not intended
> to be used.

There are three separate SSD related optimizations:

Allocation optimization is the mount time -o ssd and ssd_spread
options; which on dmcrypt devices you'll need to manually add because
the fact this is an SSD isn't passed through the device mapper
apparently.

Using single instead of duplicate metadata is a mkfs time option,
probably uses the same detection method as mount time allocation
optimization, and why you get DUP instead of single. So you have to
mkfs manually or use 'btrfs balance -mconvert=single -f' to force
changing it, forcing is required since a reduction in redunancy will
happen.

Trim, isn't used automatically, it's a mount time option, -o discard.



-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mkfs.btrfs doesn't detect SSD

[Christoph Anton Mitterer]

Hmm in fact it seems to be the kernel who wrongly, detects the type:
/sys/block/sdb/queue/rotational = 1
or more like the USB/SATA bridge simply reports it wrong.

Anyway, is there a way to override? Or will setting
/sys/block/sdb/queue/rotational = 0 give the expected behaviour?


Thanks,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Reproducible corruption issue in stable, with possible patch unmerged?

[Diego Call.]

[repost, since the previous mail was rejected by vger.kernel.org]

I got these messages in my dmesg:

[ 2587.841376] BTRFS error (device sdc1): partial page write in btrfs
with offset 0 and length 8392704
[ 2588.814182] BTRFS critical (device sdc1): bad ordered accounting
left 0 size 4096

With no other errors before. After rebooting I got btrfs
errors and widespreading filesystem corruption (pool
of three disks created with -d raid0 and -m raid1)

I reinstalled the system (current arch linux installer, which
runs 4.2) and started to restore the backup. Surprisingly,
I got exactly the same errors again. I reinstalled again,
and after rebooting to the new system, running 4.2.5,
I tried to restore the backup and got the same messages
and corruption again. Then I tried reinstalling with
the 4.1.12 LTS version, and it all worked fine.

Now, the interesting thing is that, after googling this error, I didn't
found any interesting references except a patch sent to this
mailing list which seems to fix a problem that causes the same
error output. The patch doesn't seem to have been merged:

http://lkml.iu.edu/hypermail/linux/kernel/1412.1/03297.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Process is blocked for more than 120 seconds

[Dmitry Katsubo]

Hi everyone,

I have noticed the following in the log. The system continues to run,
but I am not sure for how long it will be stable. Should I start
worrying? Thanks in advance for the opinion.

# uname -a
Linux Debian 4.2.3-2~bpo8+1 (2015-10-20) i686 GNU/Linux

# mount | grep /var
/dev/sdd2 on /var type btrfs
(rw,noatime,compress=lzo,space_cache,subvolid=258,subvol=/var)

> [Mon Nov  2 06:35:57 2015] INFO: task nscd:859 blocked for more than 120 
> seconds.
> [Mon Nov  2 06:35:57 2015]   Not tainted 4.2.0-0.bpo.1-686-pae #1
> [Mon Nov  2 06:35:57 2015] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [Mon Nov  2 06:35:57 2015] nscdD f1c7dd20 0   859  1 
> 0x
> [Mon Nov  2 06:35:57 2015]  f1c7dd40 00200082 f79de900 f1c7dd20 c10bc119 
> ffe0 f3aec740 00200246
> [Mon Nov  2 06:35:57 2015]  f74ea800 f79e3f40 f77fb800 f1c7e000 f6b381dc 
> f6b38000 f1c7dd4c c14f1fdb
> [Mon Nov  2 06:35:57 2015]  d5553960 f1c7dd70 f867672f  f77fb800 
> c1099250 d0a4be08 d9755e68
> [Mon Nov  2 06:35:57 2015] Call Trace:
> [Mon Nov  2 06:35:57 2015]  [] ? del_timer_sync+0x49/0x50
> [Mon Nov  2 06:35:57 2015]  [] ? schedule+0x2b/0x80
> [Mon Nov  2 06:35:57 2015]  [] ? 
> wait_current_trans.isra.21+0x8f/0xf0 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? wait_woken+0x80/0x80
> [Mon Nov  2 06:35:57 2015]  [] ? start_transaction+0x3d0/0x5d0 
> [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? 
> btrfs_delalloc_reserve_metadata+0x32d/0x580 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? btrfs_dirty_inode+0xb0/0xb0 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? btrfs_join_transaction+0x23/0x30 
> [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? btrfs_dirty_inode+0x39/0xb0 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? btrfs_dirty_inode+0xb0/0xb0 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? file_update_time+0x7e/0xc0
> [Mon Nov  2 06:35:57 2015]  [] ? btrfs_page_mkwrite+0x80/0x3c0 
> [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? hrtimer_cancel+0x19/0x20
> [Mon Nov  2 06:35:57 2015]  [] ? futex_wait+0x1e1/0x270
> [Mon Nov  2 06:35:57 2015]  [] ? do_page_mkwrite+0x38/0x90
> [Mon Nov  2 06:35:57 2015]  [] ? do_wp_page+0x2e2/0x6d0
> [Mon Nov  2 06:35:57 2015]  [] ? futex_wake+0x71/0x140
> [Mon Nov  2 06:35:57 2015]  [] ? kmap_atomic_prot+0xe7/0x110
> [Mon Nov  2 06:35:57 2015]  [] ? handle_mm_fault+0xd59/0x14d0
> [Mon Nov  2 06:35:57 2015]  [] ? __do_page_fault+0x18c/0x480
> [Mon Nov  2 06:35:57 2015]  [] ? __do_page_fault+0x480/0x480
> [Mon Nov  2 06:35:57 2015]  [] ? error_code+0x67/0x6c
> [Mon Nov  2 06:35:57 2015] INFO: task nscd:864 blocked for more than 120 
> seconds.
> [Mon Nov  2 06:35:57 2015]   Not tainted 4.2.0-0.bpo.1-686-pae #1
> [Mon Nov  2 06:35:57 2015] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [Mon Nov  2 06:35:57 2015] nscdD f1c87f5c 0   864  1 
> 0x
> [Mon Nov  2 06:35:57 2015]  f1c87ef4 00200082 f1c87f80 f1c87f5c 03e7 
> f1c87ee4 f3aec740 ac76c560
> [Mon Nov  2 06:35:57 2015]  f74ea800 f79e3f40 f3c7b040 f1c88000 f3c7b040 
> 0001 f1c87f00 c14f1fdb
> [Mon Nov  2 06:35:57 2015]  f3aec77c f1c87f38 c14f4265 f1c87f1c f3aec780 
> f3aec788  0125
> [Mon Nov  2 06:35:57 2015] Call Trace:
> [Mon Nov  2 06:35:57 2015]  [] ? schedule+0x2b/0x80
> [Mon Nov  2 06:35:57 2015]  [] ? rwsem_down_write_failed+0x185/0x280
> [Mon Nov  2 06:35:57 2015]  [] ? 
> call_rwsem_down_write_failed+0x6/0x8
> [Mon Nov  2 06:35:57 2015]  [] ? down_write+0x25/0x40
> [Mon Nov  2 06:35:57 2015]  [] ? vm_mmap_pgoff+0x4a/0xa0
> [Mon Nov  2 06:35:57 2015]  [] ? SyS_fstat64+0x28/0x30
> [Mon Nov  2 06:35:57 2015]  [] ? SyS_mmap_pgoff+0x110/0x210
> [Mon Nov  2 06:35:57 2015]  [] ? sysenter_do_call+0x12/0x12
> [Mon Nov  2 06:35:57 2015] INFO: task nmbd:1330 blocked for more than 120 
> seconds.
> [Mon Nov  2 06:35:57 2015]   Not tainted 4.2.0-0.bpo.1-686-pae #1
> [Mon Nov  2 06:35:57 2015] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [Mon Nov  2 06:35:57 2015] nmbdD  0  1330  1 
> 0x
> [Mon Nov  2 06:35:57 2015]  ef44bd74 00200086    
>  f3984900 
> [Mon Nov  2 06:35:57 2015]  f69e1800 f79e3f40 f3a7a800 ef44c000 d17255a0 
> d17255a0 ef44bd80 c14f1fdb
> [Mon Nov  2 06:35:57 2015]  d1725600 ef44bdc8 f86961b5 000d3fff  
> 1000  000d3000
> [Mon Nov  2 06:35:57 2015] Call Trace:
> [Mon Nov  2 06:35:57 2015]  [] ? schedule+0x2b/0x80
> [Mon Nov  2 06:35:57 2015]  [] ? 
> btrfs_start_ordered_extent+0xd5/0x100 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? wait_woken+0x80/0x80
> [Mon Nov  2 06:35:57 2015]  [] ? 
> lock_and_cleanup_extent_if_need+0x134/0x260 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? prepare_pages+0xc6/0x150 [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? __btrfs_buffered_write+0x17a/0x5e0 
> [btrfs]
> [Mon Nov  2 06:35:57 2015]  [] ? __alloc_pages_nodemask+0x133/0x880
> [Mon Nov  2 06:35:57 2015]  [] ? 

Re: Btrfs progs pre-release 4.3-rc1

[Duncan]

David Sterba posted on Fri, 06 Nov 2015 11:53:53 +0100 as excerpted:

> On Tue, Nov 03, 2015 at 12:10:14AM +, Duncan wrote:
>> David Sterba posted on Mon, 02 Nov 2015 16:14:53 +0100 as excerpted:
>> 
>> > the kernel 4.3 was released yesterday, the btrfs-progs will follow at
>> > the end of this week. I've tagged an rc1 from current devel branch.
>> > There are a lots of small invisible changes and one change in the
>> > defaults:
>> > 
>> > * mkfs: mixed mode is not forced anymore for devices smaller than 1
>> > GiB
>> 
>> It says one change in the /defaults/, but then it says mixed mode isn't
>> /forced/ anymore under a GiB.
> 
> Well, it may be a loose definition of 'default'. I meant a change in the
> current behaviour without further tuning.
> 
>> If the /defaults/ changed, is mixed mode still /recommended/ for small
>> filesystems?
> 
> Yes it is, where small remains < 1 GiB.

Thanks.  Useful information, now more important to know than ever, since 
it's no longer the under-a-gig no-additional-options default.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: boot from snapshot and take snapshot from here.

[Hugo Mills]

On Sat, Nov 07, 2015 at 08:04:01PM +0100, Jakob Schürz wrote:
> Hi there!
> 
> I can't find any Information for my Problem. And I try to explain, what
> I want.
[snip]
> BUT
> 
> When i boot from f.e. @debian-snap2, the mechanics doesn't work any longer.
> 
> btrfs subvol snapshot @debian-snap2 @debian-snap3
> 
> this works.
> 
> btrfs send -p @debian-snap2 debian-snap3 | btrfs receive /backupmountpoint
> 
> gives me an error, that btrfs can't find a subvol with a proper ID.
> 
> Ho to do this, if i want to boot from a former snapshot (in case of a
> mistaken system-upgrade) and i want to transfer the later snapshots to
> the external HD - only the differences?

   Basically, you can't right now. It's a known limitation, and can, I
think, be fixed, but it'll need a change to the send stream format,
which is a tricky migration to do (because there's currently no format
identifier in it, which makes it hard to handle both formats easily).

> There is nothing on the internet on this problem (I've found). But i
> think this is a usecase, which I'm not alone needing it...

   You're not alone. It will come eventually, but only when David's in
a position to deal with the issues of changing the send stream.

   Hugo.

-- 
Hugo Mills | "No! My collection of rare, incurable diseases!
hugo@... carfax.org.uk | Violated!"
http://carfax.org.uk/  |
PGP: E2AB1DE4  |Stimpson J. Cat, The Ren & Stimpy Show


signature.asc
Description: Digital signature

Re: boot from snapshot and take snapshot from here.

[Jakob Schürz]

Am 2015-11-07 um 20:18 schrieb Hugo Mills:
> On Sat, Nov 07, 2015 at 08:04:01PM +0100, Jakob Schürz wrote:
>> Hi there!
>>
>> I can't find any Information for my Problem. And I try to explain, what
>> I want.
> [snip]
>> BUT
>>
>> When i boot from f.e. @debian-snap2, the mechanics doesn't work any longer.
>>
>> btrfs subvol snapshot @debian-snap2 @debian-snap3
>>
>> this works.
>>
>> btrfs send -p @debian-snap2 debian-snap3 | btrfs receive /backupmountpoint
>>
>> gives me an error, that btrfs can't find a subvol with a proper ID.
>>
>> Ho to do this, if i want to boot from a former snapshot (in case of a
>> mistaken system-upgrade) and i want to transfer the later snapshots to
>> the external HD - only the differences?
> 
>Basically, you can't right now. It's a known limitation, and can, I
> think, be fixed, but it'll need a change to the send stream format,
> which is a tricky migration to do (because there's currently no format
> identifier in it, which makes it hard to handle both formats easily).
> 
>> There is nothing on the internet on this problem (I've found). But i
>> think this is a usecase, which I'm not alone needing it...
> 
>You're not alone. It will come eventually, but only when David's in
> a position to deal with the issues of changing the send stream.

OK!

I'm always happy, when i realize, it's not my tired mind, when i can't
find the solution :)

Thanks for the  info. So we will wait.

jakob


-- 
http://xundeenergie.at
http://verkehrsloesungen.wordpress.com/
http://cogitationum.wordpress.com/



signature.asc
Description: OpenPGP digital signature

Re: Reproducible corruption issue in stable, with possible patch unmerged?

[Chris Mason]

On Sat, Nov 07, 2015 at 04:36:56PM +0100, Diego Call. wrote:
> [repost, since the previous mail was rejected by vger.kernel.org]
> 
> I got these messages in my dmesg:
> 
> [ 2587.841376] BTRFS error (device sdc1): partial page write in btrfs
> with offset 0 and length 8392704
> [ 2588.814182] BTRFS critical (device sdc1): bad ordered accounting
> left 0 size 4096
> 
> With no other errors before. After rebooting I got btrfs
> errors and widespreading filesystem corruption (pool
> of three disks created with -d raid0 and -m raid1)
> 
> I reinstalled the system (current arch linux installer, which
> runs 4.2) and started to restore the backup. Surprisingly,
> I got exactly the same errors again. I reinstalled again,
> and after rebooting to the new system, running 4.2.5,
> I tried to restore the backup and got the same messages
> and corruption again. Then I tried reinstalling with
> the 4.1.12 LTS version, and it all worked fine.
> 
> Now, the interesting thing is that, after googling this error, I didn't
> found any interesting references except a patch sent to this
> mailing list which seems to fix a problem that causes the same
> error output. The patch doesn't seem to have been merged:
> 

Good catch.  Can you describe your configuration?

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cannot mount btrfs volume read/write (+task blocked backtrace)

[Frédéric]

Hi all, 

I am trying to mount a btrfs filesystem, and I have been told on 
freenode/#btrfs to try the mailing list for more precise advice.
My setup is as follow : one debian server (stretch,  4.2.0-1-amd64 #1 SMP 
Debian 4.2.3-2 (2015-10-14) x86_64) with 5 disks running in a btrfs raid6 
volume.
root@nas:~# btrfs --version
btrfs-progs v4.1.2
root@nas:~#   btrfs fi show
Label: none  uuid: 0d56cb74-65f9-4f4e-9c51-74ea286f3f79
Total devices 5 FS bytes used 2.66TiB
devid3 size 931.51GiB used 320.29GiB path /dev/sda1
devid5 size 2.73TiB used 1.76TiB path /dev/sdb1
devid6 size 2.73TiB used 1.76TiB path /dev/sde1
devid7 size 2.73TiB used 1.76TiB path /dev/sdf1
devid8 size 2.73TiB used 609.50GiB path /dev/sdd1

btrfs-progs v4.1.2
root@nas:~#   btrfs fi df /raid
Data, RAID6: total=2.66TiB, used=2.66TiB
System, RAID6: total=64.00MiB, used=416.00KiB
Metadata, RAID6: total=10.00GiB, used=8.13GiB
GlobalReserve, single: total=512.00MiB, used=544.00KiB


As you can guess, device 8 is pretty new. Device 3 is to be removed. I already 
issued a "btrfs dev del" on it (and the data was balanced to dev 8), but had to 
interrupt it (I'm not proud of that, but the server had to be turned off).
I had few hitches with this volume recently : the btrfs dev del was 
interrupted, and one of the SATA cable was defective (I saw that recently, it 
is now replaced). I ran a scrub which had not had enough time to complete. I 
can not say for sure that it is not waiting for resuming...
The volume has several snapshots (about 20 or 30, I activated snapper 1 month 
ago), and I just enabled qgroups in order to monitor snapshot disk usage. I 
know that the qgroups quotas are not updated yet : because of the bad cable, 
the latest "btrfs dev del" started to have errors, and I could not do anything 
but kill the server. If I remember correctly, the disk with the bad cable was 
devid 5 (/dev/sdb1).
I enabled qgroups during the "btrfs dev del" process.

Now, I can mount the volume with no problem in read-only (so my backups are 
up-to-date!)
If I try to mount it RW, I get the following errors in dmesg :
steps :
mount -o ro,recover,nospace_cache,clear_cache,skip_balance
(time is 28s in dmesg)
mount -o remount,rw,recover,nospace_cache,clear_cache,skip_balance
(time 83s)
dmesg :
[   28.920176] BTRFS info (device sda1): enabling auto recovery
[   28.920183] BTRFS info (device sda1): force clearing of disk cache
[   28.920187] BTRFS info (device sda1): disabling disk space caching
[   28.920190] BTRFS: has skinny extents
[   29.551170] BTRFS: bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 3434, 
gen 0
[   83.483314] BTRFS info (device sda1): disabling disk space caching
[   83.483323] BTRFS info (device sda1): enabling auto recovery
[   83.483326] BTRFS info (device sda1): enabling auto recovery
[  360.188189] INFO: task btrfs-transacti:1100 blocked for more than 120 
seconds.
[  360.188209]   Tainted: GW   4.2.0-1-amd64 #1
[  360.188214] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  360.188221] btrfs-transacti D 8109a1c0 0  1100  2 0x
[  360.188226]  8800d857eec0 0046 8800cb947e20 
88011abecd40
[  360.188229]  0246 8800cb948000 880119dc8000 
8800cb947e20
[  360.188231]  88011ae83d58 8800d8d72d48 8800d8d72da8 
8154acaf
[  360.188233] Call Trace:
[  360.188239]  [] ? schedule+0x2f/0x70
[  360.188265]  [] ? btrfs_commit_transaction+0x3ef/0xa90 
[btrfs]
[  360.188269]  [] ? wait_woken+0x80/0x80
[  360.188281]  [] ? transaction_kthread+0x224/0x240 [btrfs]
[  360.188293]  [] ? btrfs_cleanup_transaction+0x510/0x510 
[btrfs]
[  360.188296]  [] ? kthread+0xc1/0xe0
[  360.188298]  [] ? kthread_create_on_node+0x170/0x170
[  360.188301]  [] ? ret_from_fork+0x3f/0x70
[  360.188303]  [] ? kthread_create_on_node+0x170/0x170
[  480.188185] INFO: task btrfs-transacti:1100 blocked for more than 120 
seconds.
[...]

As you can see, I get an error at boot+360s (6 minutes)
The error repeats every two minutes, and stopped at boot+28minutes.
However, the "mount" process was still active, and I stopped it (in order to 
try something else) more than 3 hours later. No message appeared after this one 
(t+28m).
I also tried to mount RO, umount, then mount RW (with the same option), but 
with no success : I got the same message+backtrace at boot+4 minutes

Following an advice on #btrfs, I am currently running a btrfs check --readonly, 
but it takes a pretty long time. However, may the check fix the problem or not, 
the backtrace may be of interest for you...
I'll update the mailing-list after the btrfs-check result

Goulou.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] btrfs: clear bio reference after submit_one_bio()

[Alex Lyakas]

Hi Holger,
I think it will cause an invalid paging request, just like in case
that Naohiro has fixed.
I am not running the "latest and greatest" btrfs in my system, and it
is not easy to set it up, that's why I cannot submit patches based on
the latest code, I can only review and comment on patches.

Alex.


On Thu, Nov 5, 2015 at 3:08 PM, Holger Hoffstätte
 wrote:
> On 10/11/15 20:09, Alex Lyakas wrote:
>> Hi Naota,
>>
>> What happens if btrfs_bio_alloc() in submit_extent_page fails? Then we
>> return -ENOMEM to the caller, but we do not set *bio_ret to NULL. And
>> if *bio_ret was non-NULL upon entry into submit_extent_page, then we
>> had submitted this bio before getting to btrfs_bio_alloc(). So should
>> btrfs_bio_alloc() failure be handled in the same way?
>>
>> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
>> index 3915c94..cd443bc 100644
>> --- a/fs/btrfs/extent_io.c
>> +++ b/fs/btrfs/extent_io.c
>> @@ -2834,8 +2834,11 @@ static int submit_extent_page(int rw, struct
>> extent_io_tree *tree,
>>
>> bio = btrfs_bio_alloc(bdev, sector, BIO_MAX_PAGES,
>> GFP_NOFS | __GFP_HIGH);
>> -   if (!bio)
>> +   if (!bio) {
>> +   if (bio_ret)
>> +   *bio_ret = NULL;
>> return -ENOMEM;
>> +   }
>>
>> bio_add_page(bio, page, page_size, offset);
>> bio->bi_end_io = end_io_func;
>>
>
> Did you get any feedback on this? It seems it could cause data loss or
> corruption on allocation failures, no?
>
> -h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

boot from snapshot and take snapshot from here.

[Jakob Schürz]

Hi there!

I can't find any Information for my Problem. And I try to explain, what
I want.

There is a btrfs-partition on my laptop.
I take snapshots every hour from the subvolume @debian.

btrfs subvol snapshot @debian @debian-snap1

Then I transfer this snapshot to my external HD

btrfs send @debian-snap1 | btrfs receive /backupmountpoint

The next snapshot

btrfs subvol snapshot @debian @debian-snap2

Transfer is

btrfs send -p @debian-snap1 @debian-snap2|btrfs receive /backupmountpoint

No magic here, works fine.

BUT

When i boot from f.e. @debian-snap2, the mechanics doesn't work any longer.

btrfs subvol snapshot @debian-snap2 @debian-snap3

this works.

btrfs send -p @debian-snap2 debian-snap3 | btrfs receive /backupmountpoint

gives me an error, that btrfs can't find a subvol with a proper ID.

Ho to do this, if i want to boot from a former snapshot (in case of a
mistaken system-upgrade) and i want to transfer the later snapshots to
the external HD - only the differences?

There is nothing on the internet on this problem (I've found). But i
think this is a usecase, which I'm not alone needing it...

jakob

-- 
http://xundeenergie.at
http://verkehrsloesungen.wordpress.com/
http://cogitationum.wordpress.com/



signature.asc
Description: OpenPGP digital signature

strange "No space left on device"

[Christoph Anton Mitterer]

Hey.

I just repeatedly did the following twice on a ~8GB USB stick, under
Debian sid (ergo kernel 4.2.0-1-amd64, btrfsprogs 4.2.2-1).

First, created some GPT on the stick:
Number  Start (sector)End (sector)  Size   Code  Name
   12048 1048575   511.0 MiB   EF02  BIOS boot partition
   2 1048576 3145727   1024.0 MiB  8300  Linux filesystem
   3 3145728 4194303   512.0 MiB   8300  Linux filesystem
   4 4194304 6291455   1024.0 MiB  8300  Linux filesystem
   5 629145615687644   4.5 GiB 8300  Linux filesystem


Then filesystems:
root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-main /dev/sdb2 
btrfs-progs v4.2.2
See http://btrfs.wiki.kernel.org for more information.

Label:  boot-main
UUID:   150ee9fb-c650-4b5b-8f64-606e589e429a
Node size:  16384
Sector size:4096
Filesystem size:1.00GiB
Block group profiles:
  Data: single8.00MiB
  Metadata: DUP  59.19MiB
  System:   DUP  12.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   IDSIZE  PATH
1 1.00GiB  /dev/sdb2

root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-data /dev/sdb3
btrfs-progs v4.2.2
See http://btrfs.wiki.kernel.org for more information.

Label:  boot-data
UUID:   b1c1fc77-c965-4f0c-a2b5-44a301fd8772
Node size:  16384
Sector size:4096
Filesystem size:1.00GiB
Block group profiles:
  Data: single8.00MiB
  Metadata: DUP  59.19MiB
  System:   DUP  12.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   IDSIZE  PATH
1 1.00GiB  /dev/sdb3

root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-archive
/dev/sdb4
btrfs-progs v4.2.2
See http://btrfs.wiki.kernel.org for more information.

Label:  boot-archive
UUID:   a063cf3b-0322-4ec7-a8c1-2dabecad9f57
Node size:  16384
Sector size:4096
Filesystem size:1.00GiB
Block group profiles:
  Data: single8.00MiB
  Metadata: DUP  59.19MiB
  System:   DUP  12.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   IDSIZE  PATH
1 1.00GiB  /dev/sdb4

root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-rescue /dev/sdb5
btrfs-progs v4.2.2
See http://btrfs.wiki.kernel.org for more information.

Label:  boot-rescue
UUID:   104b7bc3-3b8c-4a08-b0a6-9172ed664e68
Node size:  16384
Sector size:4096
Filesystem size:3.98GiB
Block group profiles:
  Data: single8.00MiB
  Metadata: DUP 211.75MiB
  System:   DUP  12.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   IDSIZE  PATH
1 3.98GiB  /dev/sdb5



No errors in the kernel log.



Then I got usage info:
root@heisenberg:/data/SSS/boot# btrfs filesystem usage data/
Overall:
Device size:   1.00GiB
Device allocated:    126.38MiB
Device unallocated:  897.62MiB
Device missing:  0.00B
Used:    256.00KiB
Free (estimated):    905.62MiB  (min: 456.81MiB)
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:   16.00MiB  (used: 0.00B)

Data,single: Size:8.00MiB, Used:0.00B
   /dev/sdb3   8.00MiB

Metadata,DUP: Size:51.19MiB, Used:112.00KiB
   /dev/sdb3 102.38MiB

System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/sdb3  16.00MiB

Unallocated:
   /dev/sdb3 897.62MiB
root@heisenberg:/data/SSS/boot# btrfs filesystem usage main/
Overall:
Device size:   1.00GiB
Device allocated:    126.38MiB
Device unallocated:  897.62MiB
Device missing:  0.00B
Used:    256.00KiB
Free (estimated):    905.62MiB  (min: 456.81MiB)
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:   16.00MiB  (used: 0.00B)

Data,single: Size:8.00MiB, Used:0.00B
   /dev/sdb2   8.00MiB

Metadata,DUP: Size:51.19MiB, Used:112.00KiB
   /dev/sdb2 102.38MiB

System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/sdb2  16.00MiB

Unallocated:
   /dev/sdb2 897.62MiB
root@heisenberg:/data/SSS/boot# btrfs filesystem usage rescue/
Overall:
Device size:   3.98GiB
Device allocated:    431.50MiB
Device unallocated:    3.56GiB
Device missing:  0.00B
Used:    320.00KiB
Free (estimated):    

Re: strange "No space left on device"

[Christoph Anton Mitterer]

On Sat, 2015-11-07 at 23:30 +, Hugo Mills wrote:
>    These are all really small.
Well enough for booting =)


>    I would suggest running mkfs with --mixed for all of these
> filesystems and trying again.
I thought btrfs would do that automatically:
https://btrfs.wiki.kernel.org/index.php/FAQ#if_your_device_is_small
"Using mixed block groups is recommended for filesystems of 1GiB or
smaller and mkfs.btrfs will force mixed block groups automatically in
that case."

Anyway I even if that's the reason, than I think something's quite
wrong here... a) it doesn't happen always (I just create 10 times a fs
in the same partition, and no problem) ... b) in those cases where I
could produce the issue, it went away after a balance... so perhaps
they just just balance the fs right after mkfs o.O

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: strange "No space left on device"

[Hugo Mills]

On Sun, Nov 08, 2015 at 12:22:42AM +0100, Christoph Anton Mitterer wrote:
> Hey.
> 
> I just repeatedly did the following twice on a ~8GB USB stick, under
> Debian sid (ergo kernel 4.2.0-1-amd64, btrfsprogs 4.2.2-1).
> 
> First, created some GPT on the stick:
> Number  Start (sector)End (sector)  Size   Code  Name
>    12048 1048575   511.0 MiB   EF02  BIOS boot partition
>    2 1048576 3145727   1024.0 MiB  8300  Linux filesystem
>    3 3145728 4194303   512.0 MiB   8300  Linux filesystem
>    4 4194304 6291455   1024.0 MiB  8300  Linux filesystem
>    5 629145615687644   4.5 GiB 8300  Linux filesystem

   These are all really small.

   I would suggest running mkfs with --mixed for all of these
filesystems and trying again.

   Hugo.

> Then filesystems:
> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-main /dev/sdb2 
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
> 
> Label:  boot-main
> UUID:   150ee9fb-c650-4b5b-8f64-606e589e429a
> Node size:  16384
> Sector size:4096
> Filesystem size:1.00GiB
> Block group profiles:
>   Data: single8.00MiB
>   Metadata: DUP  59.19MiB
>   System:   DUP  12.00MiB
> SSD detected:   no
> Incompat features:  extref, skinny-metadata
> Number of devices:  1
> Devices:
>    IDSIZE  PATH
> 1 1.00GiB  /dev/sdb2
> 
> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-data /dev/sdb3
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
> 
> Label:  boot-data
> UUID:   b1c1fc77-c965-4f0c-a2b5-44a301fd8772
> Node size:  16384
> Sector size:4096
> Filesystem size:1.00GiB
> Block group profiles:
>   Data: single8.00MiB
>   Metadata: DUP  59.19MiB
>   System:   DUP  12.00MiB
> SSD detected:   no
> Incompat features:  extref, skinny-metadata
> Number of devices:  1
> Devices:
>    IDSIZE  PATH
> 1 1.00GiB  /dev/sdb3
> 
> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-archive
> /dev/sdb4
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
> 
> Label:  boot-archive
> UUID:   a063cf3b-0322-4ec7-a8c1-2dabecad9f57
> Node size:  16384
> Sector size:4096
> Filesystem size:1.00GiB
> Block group profiles:
>   Data: single8.00MiB
>   Metadata: DUP  59.19MiB
>   System:   DUP  12.00MiB
> SSD detected:   no
> Incompat features:  extref, skinny-metadata
> Number of devices:  1
> Devices:
>    IDSIZE  PATH
> 1 1.00GiB  /dev/sdb4
> 
> root@heisenberg:~# mkfs.btrfs --nodiscard --label boot-rescue /dev/sdb5
> btrfs-progs v4.2.2
> See http://btrfs.wiki.kernel.org for more information.
> 
> Label:  boot-rescue
> UUID:   104b7bc3-3b8c-4a08-b0a6-9172ed664e68
> Node size:  16384
> Sector size:4096
> Filesystem size:3.98GiB
> Block group profiles:
>   Data: single8.00MiB
>   Metadata: DUP 211.75MiB
>   System:   DUP  12.00MiB
> SSD detected:   no
> Incompat features:  extref, skinny-metadata
> Number of devices:  1
> Devices:
>    IDSIZE  PATH
> 1 3.98GiB  /dev/sdb5
> 
> 
> 
> No errors in the kernel log.
> 
> 
> 
> Then I got usage info:
> root@heisenberg:/data/SSS/boot# btrfs filesystem usage data/
> Overall:
> Device size:     1.00GiB
> Device allocated:  126.38MiB
> Device unallocated:    897.62MiB
> Device missing:    0.00B
> Used:  256.00KiB
> Free (estimated):  905.62MiB  (min: 456.81MiB)
> Data ratio:     1.00
> Metadata ratio:     2.00
> Global reserve:     16.00MiB  (used: 0.00B)
> 
> Data,single: Size:8.00MiB, Used:0.00B
>    /dev/sdb3     8.00MiB
> 
> Metadata,DUP: Size:51.19MiB, Used:112.00KiB
>    /dev/sdb3   102.38MiB
> 
> System,DUP: Size:8.00MiB, Used:16.00KiB
>    /dev/sdb3    16.00MiB
> 
> Unallocated:
>    /dev/sdb3   897.62MiB
> root@heisenberg:/data/SSS/boot# btrfs filesystem usage main/
> Overall:
> Device size:     1.00GiB
> Device allocated:  126.38MiB
> Device unallocated:    897.62MiB
> Device missing:    0.00B
> Used:  256.00KiB
> Free (estimated):  905.62MiB  (min: 456.81MiB)
> Data ratio:     1.00
> Metadata ratio:     2.00
> Global reserve:     16.00MiB  (used: 0.00B)
> 
> Data,single: Size:8.00MiB, Used:0.00B
>    /dev/sdb2     8.00MiB
> 
> Metadata,DUP: 

Re: cannot mount btrfs volume read/write (+task blocked backtrace)

[Frédéric Grelot]

After 8 hours, "btrfs check --readonly" is still "checking quota groups". It 
does not have any IO activity, but uses 100% CPU.
#top
 1143 root  20   0 2266596 2.148g   1124 R 100.0 56.0 183:37.14 btrfs check 
--readonly /dev/sda1
  

I am not sure what to do : if you have no idea, since I have less than 3Tb of 
data I will just manually degrade the volume by removing one of the disk, build 
a new btrfs on it, copy the data since I can still open the old one RO, then 
manually take devices from the old volume to new new one (converting to raid1 
first, then raid6).

Goulou.

- Mail original -
De: "Frédéric Grelot" 
À: "linux-btrfs" 
Envoyé: Samedi 7 Novembre 2015 23:20:34
Objet: cannot mount btrfs volume read/write (+task blocked backtrace)

Hi all, 

I am trying to mount a btrfs filesystem, and I have been told on 
freenode/#btrfs to try the mailing list for more precise advice.
My setup is as follow : one debian server (stretch,  4.2.0-1-amd64 #1 SMP 
Debian 4.2.3-2 (2015-10-14) x86_64) with 5 disks running in a btrfs raid6 
volume.
root@nas:~# btrfs --version
btrfs-progs v4.1.2
root@nas:~#   btrfs fi show
Label: none  uuid: 0d56cb74-65f9-4f4e-9c51-74ea286f3f79
Total devices 5 FS bytes used 2.66TiB
devid3 size 931.51GiB used 320.29GiB path /dev/sda1
devid5 size 2.73TiB used 1.76TiB path /dev/sdb1
devid6 size 2.73TiB used 1.76TiB path /dev/sde1
devid7 size 2.73TiB used 1.76TiB path /dev/sdf1
devid8 size 2.73TiB used 609.50GiB path /dev/sdd1

btrfs-progs v4.1.2
root@nas:~#   btrfs fi df /raid
Data, RAID6: total=2.66TiB, used=2.66TiB
System, RAID6: total=64.00MiB, used=416.00KiB
Metadata, RAID6: total=10.00GiB, used=8.13GiB
GlobalReserve, single: total=512.00MiB, used=544.00KiB


As you can guess, device 8 is pretty new. Device 3 is to be removed. I already 
issued a "btrfs dev del" on it (and the data was balanced to dev 8), but had to 
interrupt it (I'm not proud of that, but the server had to be turned off).
I had few hitches with this volume recently : the btrfs dev del was 
interrupted, and one of the SATA cable was defective (I saw that recently, it 
is now replaced). I ran a scrub which had not had enough time to complete. I 
can not say for sure that it is not waiting for resuming...
The volume has several snapshots (about 20 or 30, I activated snapper 1 month 
ago), and I just enabled qgroups in order to monitor snapshot disk usage. I 
know that the qgroups quotas are not updated yet : because of the bad cable, 
the latest "btrfs dev del" started to have errors, and I could not do anything 
but kill the server. If I remember correctly, the disk with the bad cable was 
devid 5 (/dev/sdb1).
I enabled qgroups during the "btrfs dev del" process.

Now, I can mount the volume with no problem in read-only (so my backups are 
up-to-date!)
If I try to mount it RW, I get the following errors in dmesg :
steps :
mount -o ro,recover,nospace_cache,clear_cache,skip_balance
(time is 28s in dmesg)
mount -o remount,rw,recover,nospace_cache,clear_cache,skip_balance
(time 83s)
dmesg :
[   28.920176] BTRFS info (device sda1): enabling auto recovery
[   28.920183] BTRFS info (device sda1): force clearing of disk cache
[   28.920187] BTRFS info (device sda1): disabling disk space caching
[   28.920190] BTRFS: has skinny extents
[   29.551170] BTRFS: bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 3434, 
gen 0
[   83.483314] BTRFS info (device sda1): disabling disk space caching
[   83.483323] BTRFS info (device sda1): enabling auto recovery
[   83.483326] BTRFS info (device sda1): enabling auto recovery
[  360.188189] INFO: task btrfs-transacti:1100 blocked for more than 120 
seconds.
[  360.188209]   Tainted: GW   4.2.0-1-amd64 #1
[  360.188214] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  360.188221] btrfs-transacti D 8109a1c0 0  1100  2 0x
[  360.188226]  8800d857eec0 0046 8800cb947e20 
88011abecd40
[  360.188229]  0246 8800cb948000 880119dc8000 
8800cb947e20
[  360.188231]  88011ae83d58 8800d8d72d48 8800d8d72da8 
8154acaf
[  360.188233] Call Trace:
[  360.188239]  [] ? schedule+0x2f/0x70
[  360.188265]  [] ? btrfs_commit_transaction+0x3ef/0xa90 
[btrfs]
[  360.188269]  [] ? wait_woken+0x80/0x80
[  360.188281]  [] ? transaction_kthread+0x224/0x240 [btrfs]
[  360.188293]  [] ? btrfs_cleanup_transaction+0x510/0x510 
[btrfs]
[  360.188296]  [] ? kthread+0xc1/0xe0
[  360.188298]  [] ? kthread_create_on_node+0x170/0x170
[  360.188301]  [] ? ret_from_fork+0x3f/0x70
[  360.188303]  [] ? kthread_create_on_node+0x170/0x170
[  480.188185] INFO: task btrfs-transacti:1100 blocked for more than 120 
seconds.
[...]

As you can see, I get