Re: [PATCH v2] Btrfs: detect corruption when non-root leaf has zero item

[Jeff Mahoney]

On 8/23/16 6:22 PM, Liu Bo wrote:
> Right now we treat leaf which has zero item as a valid one
> because we could have an empty tree, that is, a root that is
> also a leaf without any item, however, in the same case but
> when the leaf is not a root, we can end up with hitting the
> BUG_ON(1) in btrfs_extend_item() called by
> setup_inline_extent_backref().
> 
> This makes us check the situation as a corruption if leaf is
> not its own root.
> 
> Signed-off-by: Liu Bo 
> ---
> v2: fix code style.
> 
>  fs/btrfs/disk-io.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index a5a22be..8df7e73 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -559,8 +559,29 @@ static noinline int check_leaf(struct btrfs_root *root,
>   u32 nritems = btrfs_header_nritems(leaf);
>   int slot;
>  
> - if (nritems == 0)
> + if (nritems == 0) {
> + struct btrfs_root *check_root;
> +
> + key.objectid = btrfs_header_owner(leaf);
> + key.type = BTRFS_ROOT_ITEM_KEY;
> + key.offset = (u64)-1;
> +
> + check_root = btrfs_get_fs_root(root->fs_info, , false);
> + /*
> +  * The only reason we also check NULL here is that during
> +  * open_ctree() some roots has not yet been set up.
> +  */
> + if (!IS_ERR_OR_NULL(check_root)) {
> + /* if leaf is the root, then it's fine */
> + if (leaf->start !=
> + btrfs_root_bytenr(_root->root_item)) {
> + CORRUPT("non-root leaf's nritems is 0",
> + leaf, root, 0);
> + return -EIO;
> + }
> + }
>   return 0;
> + }
>  
>   /* Check the 0 item */
>   if (btrfs_item_offset_nr(leaf, 0) + btrfs_item_size_nr(leaf, 0) !=
> 

Hi Liu -

This is causing probs with integrity checking turned on.

[  124.716069] [ cut here ]
[  124.725914] kernel BUG at fs/btrfs/ctree.h:3396!
[  124.739316] invalid opcode:  [#1] PREEMPT SMP
[  124.746888] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs 
fscache iscsi_ibft iscsi_boot_sysfs af_packet ipmi_ssif igb ptp pps_core dca 
sp5100_tco fjes acpi_cpufreq shpchp i2c_piix4 kvm_amd kvm k10temp tpm_infineon 
tpm_tis tpm_tis_core ipmi_si button pcspkr serio_raw ipmi_msghandler tpm 
irqbypass nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_mod btrfs xor 
zlib_deflate ohci_pci raid6_pq ohci_hcd ehci_pci ata_generic ehci_hcd mgag200 
i2c_algo_bit drm_kms_helper usbcore syscopyarea pata_atiixp sysfillrect 
sysimgblt usb_common fb_sys_fops ttm drm sg
[  124.815657] CPU: 9 PID: 2972 Comm: mount Not tainted 4.8.0-rc4-vanilla+ #18
[  124.826173] Hardware name: HP ProLiant DL165 G7, BIOS O37 10/17/2012
[  124.836043] task: 88033b450200 task.stack: 880337a7
[  124.845445] RIP: 0010:[]  [] 
assfail.constprop.60+0x1e/0x20 [btrfs]
[  124.858936] RSP: 0018:880337a73570  EFLAGS: 00010292
[  124.867793] RAX: 0076 RBX: 8804376ef250 RCX: 81c52f08
[  124.878735] RDX: 0001 RSI: 0286 RDI: 0286
[  124.889661] RBP: 880337a73570 R08: 041a R09: 
[  124.900597] R10: 0003 R11: 0006 R12: 880337f97800
[  124.911563] R13: 0007 R14:  R15: 880435024000
[  124.922522] FS:  7fa4662c1840() GS:88043fc4() 
knlGS:
[  124.934581] CS:  0010 DS:  ES:  CR0: 80050033
[  124.944015] CR2: 7ff68dcd2095 CR3: 00033ae32000 CR4: 06e0
[  124.955036] Stack:
[  124.960294]  880337a73598 a038fb04 8804376ef250 
88043b45ebd0
[  124.971723]  88042c6225a0 880337a73618 a036a5f1 

[  124.983186]   8801 880337a736d8 
88043b45ebd0
[  124.994675] Call Trace:
[  125.000638]  [] btrfs_mark_buffer_dirty+0xf4/0x120 [btrfs]
[  125.011816]  [] __btrfs_cow_block+0x311/0x5a0 [btrfs]
[  125.022524]  [] btrfs_cow_block+0x136/0x210 [btrfs]
[  125.033025]  [] btrfs_search_slot+0x1ea/0x960 [btrfs]
[  125.043731]  [] btrfs_del_csums+0xd6/0x2b0 [btrfs]
[  125.054169]  [] ? free_extent_buffer+0x4b/0x90 [btrfs]
[  125.064999]  [] __btrfs_free_extent.isra.72+0x675/0xc60 
[btrfs]
[  125.076739]  [] 
__btrfs_run_delayed_refs.constprop.81+0x467/0x12b0 [btrfs]
[  125.089591]  [] ? btrfs_get_token_32+0x59/0xe0 [btrfs]
[  125.100486]  [] btrfs_run_delayed_refs+0x93/0x2a0 [btrfs]
[  125.111676]  [] btrfs_start_dirty_block_groups+0x299/0x410 
[btrfs]
[  125.123752]  [] btrfs_commit_transaction+0x155/0xae0 
[btrfs]
[  125.135289]  [] btrfs_create_uuid_tree+0x59/0x130 [btrfs]
[  125.146532]  [] open_ctree+0x266d/0x2860 [btrfs]
[  125.156916]  [] 

[PATCH] btrfs: introduce tickets_id to determine whether asynchronous metadata reclaim work makes progress

[Wang Xiaoguang]

In btrfs_async_reclaim_metadata_space(), we use ticket's address to
determine whether asynchronous metadata reclaim work is making progress.

ticket = list_first_entry(_info->tickets,
  struct reserve_ticket, list);
if (last_ticket == ticket) {
flush_state++;
} else {
last_ticket = ticket;
flush_state = FLUSH_DELAYED_ITEMS_NR;
if (commit_cycles)
commit_cycles--;
}

But indeed it's wrong, we should not rely on local variable's address to
do this check, because addresses may be same. In my test environment, I
dd one 168MB file in a 256MB fs, found that for this file, every time
wait_reserve_ticket() called, local variable ticket's address is same,

For above codes, assume a previous ticket's address is addrA, last_ticket
is addrA. Btrfs_async_reclaim_metadata_space() finished this ticket and
wake up it, then another ticket is added, but with the same address addrA,
now last_ticket will be same to current ticket, then current ticket's flush
work will start from current flush_state, not initial FLUSH_DELAYED_ITEMS_NR,
which may result in some enospc issues(I have seen this in my test machine).

Signed-off-by: Wang Xiaoguang 
---
 fs/btrfs/ctree.h   |  1 +
 fs/btrfs/extent-tree.c | 11 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index eff3993..33fe035 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -427,6 +427,7 @@ struct btrfs_space_info {
struct list_head ro_bgs;
struct list_head priority_tickets;
struct list_head tickets;
+   u64 tickets_id;
 
struct rw_semaphore groups_sem;
/* for block groups in our same type */
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 8c8a4d1..2f9a18f 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4966,12 +4966,12 @@ static void wake_all_tickets(struct list_head *head)
  */
 static void btrfs_async_reclaim_metadata_space(struct work_struct *work)
 {
-   struct reserve_ticket *last_ticket = NULL;
struct btrfs_fs_info *fs_info;
struct btrfs_space_info *space_info;
u64 to_reclaim;
int flush_state;
int commit_cycles = 0;
+   u64 last_tickets_id;
 
fs_info = container_of(work, struct btrfs_fs_info, async_reclaim_work);
space_info = __find_space_info(fs_info, BTRFS_BLOCK_GROUP_METADATA);
@@ -4984,8 +4984,7 @@ static void btrfs_async_reclaim_metadata_space(struct 
work_struct *work)
spin_unlock(_info->lock);
return;
}
-   last_ticket = list_first_entry(_info->tickets,
-  struct reserve_ticket, list);
+   last_tickets_id = space_info->tickets_id;
spin_unlock(_info->lock);
 
flush_state = FLUSH_DELAYED_ITEMS_NR;
@@ -5005,10 +5004,10 @@ static void btrfs_async_reclaim_metadata_space(struct 
work_struct *work)
  space_info);
ticket = list_first_entry(_info->tickets,
  struct reserve_ticket, list);
-   if (last_ticket == ticket) {
+   if (last_tickets_id == space_info->tickets_id) {
flush_state++;
} else {
-   last_ticket = ticket;
+   last_tickets_id = space_info->tickets_id;
flush_state = FLUSH_DELAYED_ITEMS_NR;
if (commit_cycles)
commit_cycles--;
@@ -5384,6 +5383,7 @@ again:
list_del_init(>list);
num_bytes -= ticket->bytes;
ticket->bytes = 0;
+   space_info->tickets_id++;
wake_up(>wait);
} else {
ticket->bytes -= num_bytes;
@@ -5426,6 +5426,7 @@ again:
num_bytes -= ticket->bytes;
space_info->bytes_may_use += ticket->bytes;
ticket->bytes = 0;
+   space_info->tickets_id++;
wake_up(>wait);
} else {
trace_btrfs_space_reservation(fs_info, "space_info",
-- 
2.9.0



--
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 1/2] btrfs-progs: mkfs: Warn user for minimal RAID5/6 devices setup

[Steven Haigh]

Is it worthwhile adding a note that RAID5 / RAID6 may very well eat your
data at this stage?

On 02/09/16 11:41, Qu Wenruo wrote:
> For RAID5, 2 devices setup is just RAID1 with more overhead.
> For RAID6, 3 devices setup is RAID1 with 3 copies, not what most user
> want.
> 
> So warn user at mkfs time for such case, and add explain in man pages.
> 
> Signed-off-by: Qu Wenruo 
> ---
>  Documentation/mkfs.btrfs.asciidoc | 15 +++
>  utils.c   | 10 --
>  2 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/mkfs.btrfs.asciidoc 
> b/Documentation/mkfs.btrfs.asciidoc
> index 98fe694..846c08f 100644
> --- a/Documentation/mkfs.btrfs.asciidoc
> +++ b/Documentation/mkfs.btrfs.asciidoc
> @@ -263,18 +263,25 @@ There are the following block group types available:
>  .2+^.^.^h| Copies   ^.^h| Parity ^.  | single  | 1||| 1/any
> -| DUP | 2 / 1 device ||| 1/any ^(see note)^
> +| DUP | 2 / 1 device ||| 1/any ^(see note1)^
>  | RAID0   |  || 1 to N | 2/any
>  | RAID1   | 2||| 2/any
>  | RAID10  | 2|| 1 to N | 4/any
> -| RAID5   | 1| 1  | 2 to N - 1 | 2/any
> -| RAID6   | 1| 2  | 3 to N - 2 | 3/any
> +| RAID5   | 1| 1  | 2 to N - 1 | 2/any ^(see note2)^
> +| RAID6   | 1| 2  | 3 to N - 2 | 3/any ^(see note3)^
>  |=
>  
> -'Note:' DUP may exist on more than 1 device if it starts on a single device 
> and
> +'Note1:' DUP may exist on more than 1 device if it starts on a single device 
> and
>  another one is added. Since version 4.5.1, *mkfs.btrfs* will let you create 
> DUP
>  on multiple devices.
>  
> +'Note2:' It's not recommended to use 2 devices RAID5. In that case,
> +parity stripe will contains the same data of data stripe, making RAID5 
> degraded
> +to RAID1 with more overhead.
> +
> +'Note3:' It's also not recommended to use 3 devices RAID6, unless one wants 
> to
> +get 3 copies RAID1, which btrfs doesn't provide yet.
> +
>  DUP PROFILES ON A SINGLE DEVICE
>  ---
>  
> diff --git a/utils.c b/utils.c
> index 82f3376..1d6879a 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -3314,6 +3314,7 @@ int test_num_disk_vs_raid(u64 metadata_profile, u64 
> data_profile,
>   u64 dev_cnt, int mixed, int ssd)
>  {
>   u64 allowed = 0;
> + u64 profile = metadata_profile | data_profile;
>  
>   switch (dev_cnt) {
>   default:
> @@ -3328,8 +3329,7 @@ int test_num_disk_vs_raid(u64 metadata_profile, u64 
> data_profile,
>   allowed |= BTRFS_BLOCK_GROUP_DUP;
>   }
>  
> - if (dev_cnt > 1 &&
> - ((metadata_profile | data_profile) & BTRFS_BLOCK_GROUP_DUP)) {
> + if (dev_cnt > 1 && profile & BTRFS_BLOCK_GROUP_DUP) {
>   warning("DUP is not recommended on filesystem with multiple 
> devices");
>   }
>   if (metadata_profile & ~allowed) {
> @@ -3349,6 +3349,12 @@ int test_num_disk_vs_raid(u64 metadata_profile, u64 
> data_profile,
>   return 1;
>   }
>  
> + if (dev_cnt == 3 && profile & BTRFS_BLOCK_GROUP_RAID6) {
> + warning("RAID6 is not recommended on filesystem with 3 devices 
> only");
> + }
> + if (dev_cnt == 2 && profile & BTRFS_BLOCK_GROUP_RAID5) {
> + warning("RAID5 is not recommended on filesystem with 2 devices 
> only");
> + }
>   warning_on(!mixed && (data_profile & BTRFS_BLOCK_GROUP_DUP) && ssd,
>  "DUP may not actually lead to 2 copies on the device, see 
> manual page");
>  
> 

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature

Re: your mail

[Jeff Mahoney]

On 9/1/16 12:44 PM, Kyle Gates wrote:
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> ow...@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
 Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
 2016 x86_64 GNU/Linux
 btrfs-progs v4.7

 Data, single: total=30.01GiB, used=18.95GiB System, single:
 total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
 used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B

 {02:50} Wed Aug 31
 [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
 fennectech:
 Sorry, try again.
 [sudo] password for fennectech:
 /: 99.8 GiB (107167244288 bytes) trimmed

 {03:08} Wed Aug 31
 [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
 fennectech:
 /: 99.9 GiB (107262181376 bytes) trimmed

   I ran these commands minutes after echother ane each time it is
 trimming the entire free space

 Anyone else seen this?   the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>>   # fstrim -v /
>>>   /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>>   # df -h /
>>>   Filesystem  Size  Used Avail Use% Mounted on
>>>   /dev/sda296G   61G   33G  66% /
>>>
>> I think you're using an old kernel, this has been working since at least 
>> 4.5, but
>> was broken in some older releases.
> 
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim 
> will only work on unallocated space.

Historically it was the opposite problem.  My fixes made it so it would
work on unallocated space.  We probably need some debugging to see why
it's not discarding extents that are allocated as block groups but
unallocated within them.

-Jeff

> On my system all space has been allocated on my root filesystem so 0 B are 
> trimmed:
> kyle@home:~$  uname -a
> Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 
> 2016 x86_64 x86_64 x86_64 GNU/Linux
> kyle@home:~$  sudo btrfs fi show /
> Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
> Total devices 2 FS bytes used 13.44GiB
> devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
> devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
> kyle@home:~$  btrfs fi df /
> Data, RAID1: total=18.97GiB, used=12.98GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=1.00GiB, used=473.83MiB
> GlobalReserve, single: total=160.00MiB, used=0.00B
> kyle@home:~$  sudo fstrim -v /
> [sudo] password for kyle:
> /: 0 B (0 bytes) trimmed
> 
> But I do have space trimmed on my home filesystem:
> kyle@home:~$  sudo btrfs fi show /home/
> Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
> Total devices 2 FS bytes used 18.63GiB
> devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
> devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
> kyle@home:~$  btrfs fi df /home/
> Data, RAID1: total=27.00GiB, used=18.46GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=2.00GiB, used=168.62MiB
> GlobalReserve, single: total=64.00MiB, used=0.00B
> kyle@home:~$  sudo fstrim -v /home
> /home: 70 GiB (75092721664 bytes) trimmed
> --
> 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
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

[PATCH 2/2] btrfs-progs: Doc: Add warning for build RAID btrfs on partions from the same device

[Qu Wenruo]

Quite a common sense for any RAID-like multi-device setup, just in case.

Signed-off-by: Qu Wenruo 
---
 Documentation/mkfs.btrfs.asciidoc | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/mkfs.btrfs.asciidoc 
b/Documentation/mkfs.btrfs.asciidoc
index 846c08f..c291714 100644
--- a/Documentation/mkfs.btrfs.asciidoc
+++ b/Documentation/mkfs.btrfs.asciidoc
@@ -271,6 +271,10 @@ There are the following block group types available:
 | RAID6   | 1| 2  | 3 to N - 2 | 3/any ^(see note3)^
 |=
 
+WARNING: It's not recommended to build btrfs with RAID0/1/10/5/6 prfiles on
+partitions from the same disk.
+Neither redundancy nor performance will be improved.
+
 'Note1:' DUP may exist on more than 1 device if it starts on a single device 
and
 another one is added. Since version 4.5.1, *mkfs.btrfs* will let you create DUP
 on multiple devices.
-- 
2.9.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

[PATCH 1/2] btrfs-progs: mkfs: Warn user for minimal RAID5/6 devices setup

[Qu Wenruo]

For RAID5, 2 devices setup is just RAID1 with more overhead.
For RAID6, 3 devices setup is RAID1 with 3 copies, not what most user
want.

So warn user at mkfs time for such case, and add explain in man pages.

Signed-off-by: Qu Wenruo 
---
 Documentation/mkfs.btrfs.asciidoc | 15 +++
 utils.c   | 10 --
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/Documentation/mkfs.btrfs.asciidoc 
b/Documentation/mkfs.btrfs.asciidoc
index 98fe694..846c08f 100644
--- a/Documentation/mkfs.btrfs.asciidoc
+++ b/Documentation/mkfs.btrfs.asciidoc
@@ -263,18 +263,25 @@ There are the following block group types available:
 .2+^. 1 &&
-   ((metadata_profile | data_profile) & BTRFS_BLOCK_GROUP_DUP)) {
+   if (dev_cnt > 1 && profile & BTRFS_BLOCK_GROUP_DUP) {
warning("DUP is not recommended on filesystem with multiple 
devices");
}
if (metadata_profile & ~allowed) {
@@ -3349,6 +3349,12 @@ int test_num_disk_vs_raid(u64 metadata_profile, u64 
data_profile,
return 1;
}
 
+   if (dev_cnt == 3 && profile & BTRFS_BLOCK_GROUP_RAID6) {
+   warning("RAID6 is not recommended on filesystem with 3 devices 
only");
+   }
+   if (dev_cnt == 2 && profile & BTRFS_BLOCK_GROUP_RAID5) {
+   warning("RAID5 is not recommended on filesystem with 2 devices 
only");
+   }
warning_on(!mixed && (data_profile & BTRFS_BLOCK_GROUP_DUP) && ssd,
   "DUP may not actually lead to 2 copies on the device, see 
manual page");
 
-- 
2.9.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

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Qu Wenruo]

At 09/01/2016 05:44 AM, Chris Murphy wrote:

On Wed, Aug 31, 2016 at 2:49 PM, Ronan Arraes Jardim Chagas
 wrote:

Hi guys!

And the problem happened again. This time, I was only using Mozilla
Firefox. I could get the very first message after the error. I hope it
brings more information:

[28039.672199] [ cut here ]
[28039.672253] WARNING: CPU: 3 PID: 31800 at ../fs/btrfs/qgroup.c:2667
btrfs_qgroup_free_meta+0x88/0x90 [btrfs]



Does this file system have quota enabled?

I'm testing this right now and can't even figure out how to determine
when quota is enabled on a Btrfs file system. There's enable, disable,
and rescan. If it's enabled or disabled, I get the same message if I
rescan. If I mount the file system with quota previously enabled,
there is no mount time notification that quota is enabled.

I sincerely hope opensuse isn't enabled quota by default.




The　kernel warning is interesting.

It means qgroup is underflowing its reserved metadata space.
However although it's a warning, it won't really under flow the numbers, 
but decrease it to zero.


It shows there is something wrong with metadata allocation, but won't 
directly cause quota corruption.


Quota uses two isolated different system, one extent based for qgroup 
numbers,

and one reserved space based for reserved space.

The latter one is only used to prevent user from exceeding qgroup limit, 
and if user doesn't use limit, it won't cause any qgroup corruption or 
ENOSPC.


Further more, if it's qgroup reserved space causing anything wrong, it 
won't return -ENOSPC, but -EDQUOT.


So, just as Wang suspected, there is something wrong with metadata 
allocation, causing the problem and triggering the qgroup warning.


Thankg,
Qu


--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Chris Murphy]

On Thu, Sep 1, 2016 at 12:47 PM, Austin S. Hemmelgarn
 wrote:


> 2. Snapper's default snapshot creation configuration is absolutely
> pathological in nature, generating insane amounts of background resource
> usage and taking up huge amounts of space.  If this were changed, you would
> be a lot less dependent on being able to free up snapshots based on space
> usage.

That's diplomatic.

They know all of this already though, but instead of toning down
snapper defaults, they're amping up the voluming by enabling quotas
instead.

There is only one logical reason for this that I can thing of. They're
trying to increase problem reports, presumably in order to smooth out
noisy data, maybe even by getting better bug reports like Ronan's. But
I think this is a specious policy.

> It's poor choices like this that fall into the category of 'Ooh, this looks
> cool, let's do it!' made by major distros that are most of the reason that
> BTRFS has such a bad reputation right now.

Over on Factory list, they're trying to have this two ways. First
they're saying quotas are stable as they've implemented them in the
Leap 4.4 kernel. And they consider the btrfs-progs man page warning
that quotas aren't yet stable even in 4.7, and aren't recommended
unless the user will use them, is a bug that should be removed from
their copy of the man page.

So, what are they using? Pulling out such warnings doesn't make
upstream code backported to their 4.4 kernel magically stable. If
they're using out of tree quota code, fine, remove the warnings. But
then, what is this code? How does it interact with upstream kernels?



-- 
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Chris Murphy]

On Thu, Sep 1, 2016 at 5:51 PM, Paul Jones  wrote:
>> -Original Message-
>> From: ch...@colorremedies.com [mailto:ch...@colorremedies.com] On
>>
>> On Thu, Sep 1, 2016 at 12:51 AM, Paul Jones  wrote:
>> >> -Original Message-
>> >> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> >> ow...@vger.kernel.org] On Behalf Of Chris Murphy
>> >> Sent: Thursday, 1 September 2016 7:59 AM
>> >> To: Btrfs BTRFS 
>> >> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local
>> >> backref count" messages
>> >>
>> >> This is still happening with btrfs-progs 4.7.1 and there is zero
>> >> information in the long result what to do about the problem, and
>> >> whether it's sane to try have --repair fix it, let alone what the original
>> cause of the problem was.
>> >
>> > I just potentially damaged a perfectly good filesystem because of this. I 
>> > was
>> getting hundreds of "Incorrect local backref count" so I decided to try 
>> repair,
>> which seemed to complete ok. I then rescanned without repair and btrfs
>> check eventually crashed with an assertion. That's when I figured something
>> may be wrong.
>>
>> Wait, so you did a --repair and then the following-up check crashes?
>> But does the file system mount and does it still work? The first is bad 
>> enough,
>> but if it won't mount this is terrible.
>
> Correct. I forgot to mention the crash was with btrfs-progs 4.7.1 and kernel 
> 4.7.2. After that I reverted to btrfs-progs 4.6.1 and kernel 4.6.7
> The filesystem still mounted, so I tried to run scrub but that got stuck at 0 
> bytes (with no errors). I reset the system (reboot didn't finish) and run 
> repair a few more times, and even though there were still errors every time I 
> noticed the last few errors appeared to be the same.
> I mounted and tried scrub again, which worked the second time. I let it run 
> overnight and it didn't find any errors. I'm just about to rsync (with 
> checksums) from the backup to verify the data is still good.
>
> I'd suggest btrfs-progs 4.7.x is withdrawn until this can be fixed.

Yeah upstream can't really do that, it's up to the distros. The main
thing though is that it didn't actually make the file system worse
off, it just sounds like it wasted some time on your end.

My complaint about this is I have no idea what the messages mean, how
big of a problem they are, whether they should be repaired, and what
to do about the fact they claim to be repaired but aren't.



-- 
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: btrfstune settings

[Oliver Freyermuth]

Hi,

Am 01.09.2016 um 19:14 schrieb David Sterba:
> all your questions should be now answered and documentation cross
> referenced among the relevant manual pages (will be synced to wiki at
> release time:
> 
> https://github.com/kdave/btrfs-progs/blob/devel/Documentation/mkfs.btrfs.asciidoc
> https://github.com/kdave/btrfs-progs/blob/devel/Documentation/btrfstune.asciidoc
> https://github.com/kdave/btrfs-progs/blob/devel/Documentation/btrfs-man5.asciidoc
> 
> see sections 'FILESYSTEM FEATURES'.
> 
Thanks a lot for this documentation effort! Just to confirm, this indeed
answers all my questions as a user.

I hope it will be helpful to many other btrfs-users in the future.

Best wishes,
Oliver
--
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Chris Murphy]

OK I filed a bug:

progs 4.7.x, numerous incorrect backrefs are not fixed with --repair
https://bugzilla.kernel.org/show_bug.cgi?id=155791
--
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Paul Jones]

> -Original Message-
> From: ch...@colorremedies.com [mailto:ch...@colorremedies.com] On
> 
> On Thu, Sep 1, 2016 at 12:51 AM, Paul Jones  wrote:
> >> -Original Message-
> >> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> >> ow...@vger.kernel.org] On Behalf Of Chris Murphy
> >> Sent: Thursday, 1 September 2016 7:59 AM
> >> To: Btrfs BTRFS 
> >> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local
> >> backref count" messages
> >>
> >> This is still happening with btrfs-progs 4.7.1 and there is zero
> >> information in the long result what to do about the problem, and
> >> whether it's sane to try have --repair fix it, let alone what the original
> cause of the problem was.
> >
> > I just potentially damaged a perfectly good filesystem because of this. I 
> > was
> getting hundreds of "Incorrect local backref count" so I decided to try 
> repair,
> which seemed to complete ok. I then rescanned without repair and btrfs
> check eventually crashed with an assertion. That's when I figured something
> may be wrong.
> 
> Wait, so you did a --repair and then the following-up check crashes?
> But does the file system mount and does it still work? The first is bad 
> enough,
> but if it won't mount this is terrible.

Correct. I forgot to mention the crash was with btrfs-progs 4.7.1 and kernel 
4.7.2. After that I reverted to btrfs-progs 4.6.1 and kernel 4.6.7
The filesystem still mounted, so I tried to run scrub but that got stuck at 0 
bytes (with no errors). I reset the system (reboot didn't finish) and run 
repair a few more times, and even though there were still errors every time I 
noticed the last few errors appeared to be the same.
I mounted and tried scrub again, which worked the second time. I let it run 
overnight and it didn't find any errors. I'm just about to rsync (with 
checksums) from the backup to verify the data is still good.

I'd suggest btrfs-progs 4.7.x is withdrawn until this can be fixed.

Paul.

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Chris Murphy]

On Thu, Sep 1, 2016 at 7:21 AM, Austin S. Hemmelgarn
 wrote:

> Yes, you can just run `btrfs quota disable /` and it should work.  This
> ironically reiterates that one of the bigger problems with BTRFS is that
> distros are enabling unstable and known broken features by default on
> install.  I was pretty much dumbfounded when I first learned that OpenSUSE
> is enabling BTRFS qgroups by default since they are known to not work
> reliably and cause all kinds of issues.

Yes, I've just confirmed this on the OpenSUSE Factory mailing list.
[1] This is default on Tumbleweed (devel) and Leap (stable), and also
SLE 12 SP2.

The feature that depends on it, that's actually enabling it is snapper:
http://snapper.io/2016/05/18/space-aware-cleanup.html

That feature says "btrfs quota support looks mature enough" which is
big news to me. If it's that mature, why not make it the mkfs default?
Just turn it on for everyone out of the gate? And if it isn't that
mature, is it really appropriate for broad, by default, silent
deployment for opensuse stable, and SUSE enterprise? I'm surprised no
one said on this list that qgroups were stable enough for widespread
testing for list regulars first. It just suddenly ends up enabled
across three major distro outputs?

Even the fucking error messages were misleading. It wasn't until the
most recent call trace that qgroups was even considered as possibly
being related to this. How is it that busting a quota limit doesn't
cause a very explicit quota related message, rather than a generic
enospc?


[1] https://lists.opensuse.org/opensuse-factory/2016-09/msg00033.html


-- 
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Chris Murphy]

OK so I have a 2nd volume, which is only ever used to 'btrfs receive'
from the 1st volume. The 2nd volume is never persistently mounted. But
it too has bunches of these incorrect backref messages, where
btrfs-progs 4.6.1 comes up clean. A 3rd volume, is only ever used to
receive rsync from the 1st and it comes up clean with 4.6.1, and
4.7.1, i.e. no such incorrect backref messages.

The 1st volume says:
found 438074621952 bytes used err is 0

So if "err is 0" then there should be nothing to fix.

I'm going to btrfs check and btrfs-image the 1st volume to capture the
current state, and then try a --repair and if it breaks the file
system I'm probably going to go ballistic...


---
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: [PATCH] btrfs: do not decrease bytes_may_use when replaying extents

[Josef Bacik]

On 09/01/2016 11:36 AM, David Sterba wrote:

CC Josef. It's a followup of patch that went to 4.8-rc4 so we'd better
get it to 4.8.

On Fri, Aug 26, 2016 at 11:33:14AM +0800, Wang Xiaoguang wrote:

When replaying extents, there is no need to update bytes_may_use
in btrfs_alloc_logged_file_extent(), otherwise it'll trigger a
WARN_ON about bytes_may_use.

Fixes: ("btrfs: update btrfs_space_info's bytes_may_use timely")
Signed-off-by: Wang Xiaoguang 


Reviewed-by: Josef Bacik 

Thanks,

Josef

--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Ronan Arraes Jardim Chagas]

Hi Jeff,

Em Qui, 2016-09-01 às 13:12 -0400, Jeff Mahoney escreveu:
> It's not.  We use qgroups because that's the only way we can track
> how
> much space each subvolume is using, regardless of whether anyone
> wants
> to do enforcement.  When it's working properly, snapper can make use
> of
> that information to make informed decisions on how much space will
> actually be released when removing old snapshots.
> 

Given that, what am I loosing by disabling qgroups here? Will I still
be able to recover my machine using snapshots (this saved my two or
three times)?

Best regards,
Ronan Arraes
--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Chris Murphy]

On Thu, Sep 1, 2016 at 11:12 AM, Jeff Mahoney  wrote:
> On 9/1/16 1:04 PM, Austin S. Hemmelgarn wrote:
>> On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:
>>> Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
 Yes, you can just run `btrfs quota disable /` and it should
 work.  This
 ironically reiterates that one of the bigger problems with BTRFS is
 that
 distros are enabling unstable and known broken features by default
 on
 install.  I was pretty much dumbfounded when I first learned that
 OpenSUSE is enabling BTRFS qgroups by default since they are known
 to
 not work reliably and cause all kinds of issues.
>>>
>>> Thanks Austin! I executed the command and now I get:
>>>
>>> btrfs qgroup show /
>>> ERROR: can't perform the search - No such file or directory
>>> ERROR: can't list qgroups: No such file or directory
>>>
>>> as expected. Now I will wait for +- 1 week to see if the problem will
>>> occur and, if not, I will send an e-mail to openSUSE factory mailing
>>> list to start a discussion if it is better to not enable qgroups by
>>> default.
>> I have a feeling that you'll probably have no issues.
>>
>> As far as having qgroups enabled by default, I think the reasoning is to
>> emulate having separate filesystems with their own space limits.  I can
>
> It's not.  We use qgroups because that's the only way we can track how
> much space each subvolume is using, regardless of whether anyone wants
> to do enforcement.  When it's working properly, snapper can make use of
> that information to make informed decisions on how much space will
> actually be released when removing old snapshots.
>
>> entirely understand this use case, and TBH it's about the only use case
>> I'd consider quota groups for (per-user subvolumes for home directories
>> are great, but there are numerous perfectly legitimate reasons to have
>> very large amounts of data in your home directory for very short periods
>> of time, so I wouldn't personally use qgroups there).  The problem
>> arises from the fact that it doesn't _look_ like separate filesystems
>> (single entry in df, all the mounts point at the same device, etc), and
>
> On SUSE-based kernels, the inodes on different subvolumes report the
> anonymous device associated with the subvolume.
>
> That said, I have a WIP that creates (and auto-tears down) vfsmounts for
> each subvolume.  It's not all the way to a working df that would use the
> qgroup information to report space usage, but it's a start.


Jeff, I'm a little bit irritated because I initially suspected in this
thread that this was an opensuse issue. That I questioned the kernel
as the source is really beside the point. You didn't even recognize
this might be quota related based on what was going on, because you
bounced him back to this list when I suggested he take the issue to
the opensuse-factory list.

What Ronan was reporting was behavior that no one on this list has
ever previously reported. And upstream does not have quotas enabled by
default so there is no reason why any regular testers here would have
come across this.

So now we come full circle and I have to call this a misfeature that's
trying to make up for another one, which is neurotic levels of
snapshots taken by snapper out of the box. There is no good goddamn
reason for it to take 100 read only snapshots in two fucking days.
It's any wonder why the results are pathological.

-- 
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: btrfstune settings

[David Sterba]

Hi,

On Sun, Aug 28, 2016 at 05:42:39AM +0200, Oliver Freyermuth wrote:
> I hope this is the correct place to ask, the wiki and manpages did not
> help me on these questions. 
> 
> BTRFS has gained extended inode refs, skinny metadata and no-holes
> quite a while ago and these are now the defaults for new mkfs.btrfs.
> btrfstune can activate those features. 
> 
> However, I miss two things: 
> - How do I see on an existing FS which of these features are on? 
>   btrfstune (it seems) can only "set", but not "get" the feature flags. 
> - Is it worthwhile / recommended / safe to activate those on existing FS? 
>   Are there any steps (e.g. balancing metadata with -musage=0, I'd
>   guess) needed to make them become active afterwards? 
> 
> If there is any documentation on this and I missed it, please RTFM me. 

all your questions should be now answered and documentation cross
referenced among the relevant manual pages (will be synced to wiki at
release time:

https://github.com/kdave/btrfs-progs/blob/devel/Documentation/mkfs.btrfs.asciidoc
https://github.com/kdave/btrfs-progs/blob/devel/Documentation/btrfstune.asciidoc
https://github.com/kdave/btrfs-progs/blob/devel/Documentation/btrfs-man5.asciidoc

see sections 'FILESYSTEM FEATURES'.
--
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Chris Murphy]

On Thu, Sep 1, 2016 at 11:59 AM, Chris Murphy  wrote:
> OK so I have a 2nd volume, which is only ever used to 'btrfs receive'
> from the 1st volume. The 2nd volume is never persistently mounted. But
> it too has bunches of these incorrect backref messages, where
> btrfs-progs 4.6.1 comes up clean. A 3rd volume, is only ever used to
> receive rsync from the 1st and it comes up clean with 4.6.1, and
> 4.7.1, i.e. no such incorrect backref messages.
>
> The 1st volume says:
> found 438074621952 bytes used err is 0
>
> So if "err is 0" then there should be nothing to fix.
>
> I'm going to btrfs check and btrfs-image the 1st volume to capture the
> current state, and then try a --repair and if it breaks the file
> system I'm probably going to go ballistic...

OK so I did a repair on the primary volume, it claim to fix a bunch of
stuff, without errors. It mounts fine afterward, just like it did
before repair. And a subsequent check still finds all kinds of backref
problems that were in fact not fixed even though repair claimed to fix
them. But it doesn't crash at least.

I'll file a bug on the Ux of this, which is pretty bad, aside from the
fact it appears to not repair what it claims to repair.

Example from repair:

adding new data backref on 16913485824 root 659 owner 143234 offset 0 found 1

and from the after check
Backref 16913485824 root 659 owner 143234 offset 0 num_refs 0 not
found in extent tree
Incorrect local backref count on 16913485824 root 659 owner 143234
offset 0 found 1 wanted 0 back 0x55e44e85ccd0
Incorrect local backref count on 16913485824 root 659 owner 143234
offset 0 found 0 wanted 1 back 0x55e44eb83910
Backref disk bytenr does not match extent record, bytenr=16913485824,
ref bytenr=79553
Backref bytes do not match extent backref, bytenr=16913485824, ref
bytes=7577600, backref bytes=4096
Backref 16913485824 root 659 owner 143233 offset 0 num_refs 0 not
found in extent tree

Which is identical to what's found in the before check.




-- 
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Austin S. Hemmelgarn]

On 2016-09-01 13:12, Jeff Mahoney wrote:

On 9/1/16 1:04 PM, Austin S. Hemmelgarn wrote:

On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:

Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:

Yes, you can just run `btrfs quota disable /` and it should
work.  This
ironically reiterates that one of the bigger problems with BTRFS is
that
distros are enabling unstable and known broken features by default
on
install.  I was pretty much dumbfounded when I first learned that
OpenSUSE is enabling BTRFS qgroups by default since they are known
to
not work reliably and cause all kinds of issues.


Thanks Austin! I executed the command and now I get:

btrfs qgroup show /
ERROR: can't perform the search - No such file or directory
ERROR: can't list qgroups: No such file or directory

as expected. Now I will wait for +- 1 week to see if the problem will
occur and, if not, I will send an e-mail to openSUSE factory mailing
list to start a discussion if it is better to not enable qgroups by
default.

I have a feeling that you'll probably have no issues.

As far as having qgroups enabled by default, I think the reasoning is to
emulate having separate filesystems with their own space limits.  I can


It's not.  We use qgroups because that's the only way we can track how
much space each subvolume is using, regardless of whether anyone wants
to do enforcement.  When it's working properly, snapper can make use of
that information to make informed decisions on how much space will
actually be released when removing old snapshots.

This is all well and good, but it ignores a few specific things:
1. There are numerous known issues with qgroups right now.  This 
includes among other things returning ENOSPC when it should return 
EDQUOT (this isn't your fault, but you haven't tried to fix it either), 
and all kinds of general usability issues (systems tend to misbehave 
when at or near the quotas for example).
2. Snapper's default snapshot creation configuration is absolutely 
pathological in nature, generating insane amounts of background resource 
usage and taking up huge amounts of space.  If this were changed, you 
would be a lot less dependent on being able to free up snapshots based 
on space usage.
3. It is fully possible (now, it may not have been when this choice was 
made) to get this info without using qgroups.  btrfs filesystem du can 
be used to determine essentially the same information (summing the 
values in the second column will give you a reasonable estimate of how 
much space deleting the snapshot will free).
4. Enabling such a marginal technology without user intervention with no 
warnings about it or other notice that it's being used is a pretty solid 
example of something that a developer should not do.


It's poor choices like this that fall into the category of 'Ooh, this 
looks cool, let's do it!' made by major distros that are most of the 
reason that BTRFS has such a bad reputation right now.  This is not 
something that should reasonably be on a production system, especially 
considering that even most of the BTRFS developers don't use qgroups, 
and that apparently your own customer support people couldn't tell that 
qgroups were to blame (seriously, your _ABSOLUTE FIRST SUGGESTION_ 
should have been to disable qgroups and see if the issue went away).


I get that you want something on par with Windows Restore Points or the 
bootable snapshot functionality provided by ZFS on Solaris, but qgroups 
really aren't at all essential to that, and even if they were, such 
functionality isn't even remotely ready for production usage on Linux yet.



entirely understand this use case, and TBH it's about the only use case
I'd consider quota groups for (per-user subvolumes for home directories
are great, but there are numerous perfectly legitimate reasons to have
very large amounts of data in your home directory for very short periods
of time, so I wouldn't personally use qgroups there).  The problem
arises from the fact that it doesn't _look_ like separate filesystems
(single entry in df, all the mounts point at the same device, etc), and


On SUSE-based kernels, the inodes on different subvolumes report the
anonymous device associated with the subvolume.

That said, I have a WIP that creates (and auto-tears down) vfsmounts for
each subvolume.  It's not all the way to a working df that would use the
qgroup information to report space usage, but it's a start.
So in other words even more dependence on a feature that doesn't even 
work reliably?


--
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: your mail

[M G Berberich]

Am Donnerstag, den 01. September schrieb Austin S. Hemmelgarn:
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> > > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> > > 2016 x86_64 GNU/Linux
> > > btrfs-progs v4.7
> > > 
> > > Data, single: total=30.01GiB, used=18.95GiB
> > > System, single: total=4.00MiB, used=16.00KiB
> > > Metadata, single: total=1.01GiB, used=422.17MiB
> > > GlobalReserve, single: total=144.00MiB, used=0.00B
> > > 
> > > {02:50} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > Sorry, try again.
> > > [sudo] password for fennectech:
> > > /: 99.8 GiB (107167244288 bytes) trimmed
> > > 
> > > {03:08} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > /: 99.9 GiB (107262181376 bytes) trimmed
> > > 
> > >   I ran these commands minutes after echother ane each time it is
> > > trimming the entire free space
> > > 
> > > Anyone else seen this?   the filesystem is the root FS and is compressed
> > 
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> > 
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> > 
> > even if there is 33G unused space ob the fs:
> > 
> >   # df -h /
> >   Filesystem  Size  Used Avail Use% Mounted on
> >   /dev/sda296G   61G   33G  66% /
> > 
> I think you're using an old kernel, this has been working since at least
> 4.5, but was broken in some older releases.

No, I’m always running a fairly up-to-date vanilla kernel on this
system. At the moment it’s:

  Linux hermione 4.7.2 #4 SMP PREEMPT Wed Aug 24 17:12:03 CEST 2016 x86_64 
GNU/Linux

I’m running kernels ≥ 4.5.0 since about April and I first reported this
problem at 7 Jul 2016 (Subject: fstrim problem/bug) probably with a
4.6.3 kernel.

MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 
--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Jeff Mahoney]

On 9/1/16 1:04 PM, Austin S. Hemmelgarn wrote:
> On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:
>> Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
>>> Yes, you can just run `btrfs quota disable /` and it should
>>> work.  This
>>> ironically reiterates that one of the bigger problems with BTRFS is
>>> that
>>> distros are enabling unstable and known broken features by default
>>> on
>>> install.  I was pretty much dumbfounded when I first learned that
>>> OpenSUSE is enabling BTRFS qgroups by default since they are known
>>> to
>>> not work reliably and cause all kinds of issues.
>>
>> Thanks Austin! I executed the command and now I get:
>>
>> btrfs qgroup show /
>> ERROR: can't perform the search - No such file or directory
>> ERROR: can't list qgroups: No such file or directory
>>
>> as expected. Now I will wait for +- 1 week to see if the problem will
>> occur and, if not, I will send an e-mail to openSUSE factory mailing
>> list to start a discussion if it is better to not enable qgroups by
>> default.
> I have a feeling that you'll probably have no issues.
> 
> As far as having qgroups enabled by default, I think the reasoning is to
> emulate having separate filesystems with their own space limits.  I can

It's not.  We use qgroups because that's the only way we can track how
much space each subvolume is using, regardless of whether anyone wants
to do enforcement.  When it's working properly, snapper can make use of
that information to make informed decisions on how much space will
actually be released when removing old snapshots.

> entirely understand this use case, and TBH it's about the only use case
> I'd consider quota groups for (per-user subvolumes for home directories
> are great, but there are numerous perfectly legitimate reasons to have
> very large amounts of data in your home directory for very short periods
> of time, so I wouldn't personally use qgroups there).  The problem
> arises from the fact that it doesn't _look_ like separate filesystems
> (single entry in df, all the mounts point at the same device, etc), and

On SUSE-based kernels, the inodes on different subvolumes report the
anonymous device associated with the subvolume.

That said, I have a WIP that creates (and auto-tears down) vfsmounts for
each subvolume.  It's not all the way to a working df that would use the
qgroup information to report space usage, but it's a start.

-Jeff


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Jeff Mahoney]

On 9/1/16 1:39 PM, Ronan Arraes Jardim Chagas wrote:
> Hi Jeff,
> 
> Em Qui, 2016-09-01 às 13:12 -0400, Jeff Mahoney escreveu:
>> It's not.  We use qgroups because that's the only way we can track
>> how
>> much space each subvolume is using, regardless of whether anyone
>> wants
>> to do enforcement.  When it's working properly, snapper can make use
>> of
>> that information to make informed decisions on how much space will
>> actually be released when removing old snapshots.
>>
> 
> Given that, what am I loosing by disabling qgroups here? Will I still
> be able to recover my machine using snapshots (this saved my two or
> three times)?

Absolutely.  It doesn't affect the ability to take, retain, or recover
using snapshots.  It only affects the ability to see how much space a
particular snapshot is using on disk, both from the user wanting to know
and snapper using it to make retention decisions.  Snapper can handle
qgroups not being there.

-Jeff

-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature

Re:

[Kai Krakow]

Am Wed, 31 Aug 2016 23:10:13 -0400
schrieb Jeff Mahoney :

> On 8/31/16 10:02 PM, Fennec Fox wrote:
> > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
> > UTC 2016 x86_64 GNU/Linux
> > btrfs-progs v4.7
> > 
> > Data, single: total=30.01GiB, used=18.95GiB
> > System, single: total=4.00MiB, used=16.00KiB
> > Metadata, single: total=1.01GiB, used=422.17MiB
> > GlobalReserve, single: total=144.00MiB, used=0.00B
> > 
> > {02:50} Wed Aug 31
> > [fennectech@Titanium ~]$  sudo fstrim -v /
> > [sudo] password for fennectech:
> > Sorry, try again.
> > [sudo] password for fennectech:
> > /: 99.8 GiB (107167244288 bytes) trimmed
> > 
> > {03:08} Wed Aug 31
> > [fennectech@Titanium ~]$  sudo fstrim -v /
> > [sudo] password for fennectech:
> > /: 99.9 GiB (107262181376 bytes) trimmed
> > 
> >   I ran these commands minutes after echother ane each time it is
> > trimming the entire free space
> > 
> > Anyone else seen this?   the filesystem is the root FS and is
> > compressed 
> 
> Yes.  It's working as intended.  We don't track what space has already
> been trimmed anywhere, so it trims all unallocated space.

I wonder, does it work in a multi device scenario? When btrfs pools
multiple devices together?

I ask because fstrim seems to always report the estimated free space,
not the raw free space, as trimmed.

OTOH, this may simply be because btrfs reports 1.08 TiB unallocated
while fstrim reports 1.2 TB trimmed (and not TiB) - which when
"converted" (1.08 * 1024^4 / 1000^4 ~= 1.18) perfectly rounds to 1.2.
Coincidence is free estimated space is 1.19 TiB for me (which would also
round to 1.2) and these numbers, as they are in the TB range, won't
change so fast for me.


-- 
Regards,
Kai

Replies to list-only preferred.


pgpL2kWoJX9d0.pgp
Description: Digitale Signatur von OpenPGP

[OT] Re: Balancing subvolume on a specific device

[Kai Krakow]

Am Sat, 20 Aug 2016 06:30:11 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:

> There's at least three other options to try to get what you mention, 
> however.  FWIW, I'm a gentooer and thus build everything from sources 
> here, and use ccache myself.  What I do is put all my build stuff,
> the gentoo git and assorted overlay git trees, ccache, kernel
> sources, the binpkg cache, etc, all on a separate "build" btrfs on
> normal partitions, / not/ a subvolume.  That way it can go wherever I
> want, and it, along with the main system (/) and /home, but /not/ my
> media partition (all of which are fully independent filesystems on
> their own partitions, most of them btrfs raid1 on a parallel set of
> partitions on a pair of ssds), on ssd. Works great. =:^)

Off topic: Is ccache really that helpful? I dumped it a few years ago
after getting some build errors and/or packaging bugs with it (software
that would just segfault when built with ccache), and in the end it
didn't give a serious speed boost anyways after comparing the genlop
results. What would help a whole lot more would be to cache this really
really inefficient configure tool of hell which often runs much longer
than the build phase of the whole source itself.

I now moved to building inside tmpfs (/var/tmp/portage mounted as 32GB
tmpfs with x-systemd.automount), added around 30GB of swap space just
in case. I'm running on 16GB of RAM and found around half of my RAM
almost always sits there doing nothing. Even building chromium and
libreoffice at the same time shows no problems with this setup. Plus,
it's a whole lot faster than building on the native fs (even if I'm
using bcache). And I'm building more relaxed since my SSD is wearing
slower - Gentoo emerge can put a lot of burden on the storage.

-- 
Regards,
Kai

Replies to list-only preferred.

--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Ronan Arraes Jardim Chagas]

Hi Jeff,

Em Qui, 2016-09-01 às 13:43 -0400, Jeff Mahoney escreveu:
> Absolutely.  It doesn't affect the ability to take, retain, or
> recover
> using snapshots.  It only affects the ability to see how much space a
> particular snapshot is using on disk, both from the user wanting to
> know
> and snapper using it to make retention decisions.  Snapper can handle
> qgroups not being there.
> 

Thanks for the prompt answer. I'm glad because space is not a concern
here, at least now :) Hence, I have plenty time to wait for a proper
fix. Until there, I will try to keep my snapshot count low.
--
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: your mail

[Kyle Gates]

> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
> Sent: Thursday, September 01, 2016 6:18 AM
> To: linux-btrfs@vger.kernel.org
> Subject: Re: your mail
> 
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> >> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
> UTC
> >> 2016 x86_64 GNU/Linux
> >> btrfs-progs v4.7
> >>
> >> Data, single: total=30.01GiB, used=18.95GiB System, single:
> >> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
> >> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
> >>
> >> {02:50} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> Sorry, try again.
> >> [sudo] password for fennectech:
> >> /: 99.8 GiB (107167244288 bytes) trimmed
> >>
> >> {03:08} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> /: 99.9 GiB (107262181376 bytes) trimmed
> >>
> >>   I ran these commands minutes after echother ane each time it is
> >> trimming the entire free space
> >>
> >> Anyone else seen this?   the filesystem is the root FS and is compressed
> >
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> >
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> >
> > even if there is 33G unused space ob the fs:
> >
> >   # df -h /
> >   Filesystem  Size  Used Avail Use% Mounted on
> >   /dev/sda296G   61G   33G  66% /
> >
> I think you're using an old kernel, this has been working since at least 4.5, 
> but
> was broken in some older releases.

M G is running 4.7.2
The problem is that all space has been allocated by block groups and fstrim 
will only work on unallocated space.

On my system all space has been allocated on my root filesystem so 0 B are 
trimmed:
kyle@home:~$  uname -a
Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
kyle@home:~$  sudo btrfs fi show /
Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
Total devices 2 FS bytes used 13.44GiB
devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
kyle@home:~$  btrfs fi df /
Data, RAID1: total=18.97GiB, used=12.98GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=473.83MiB
GlobalReserve, single: total=160.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /
[sudo] password for kyle:
/: 0 B (0 bytes) trimmed

But I do have space trimmed on my home filesystem:
kyle@home:~$  sudo btrfs fi show /home/
Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
Total devices 2 FS bytes used 18.63GiB
devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
kyle@home:~$  btrfs fi df /home/
Data, RAID1: total=27.00GiB, used=18.46GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=2.00GiB, used=168.62MiB
GlobalReserve, single: total=64.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /home
/home: 70 GiB (75092721664 bytes) trimmed
--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Austin S. Hemmelgarn]

On 2016-09-01 12:34, Ronan Arraes Jardim Chagas wrote:

Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:

Yes, you can just run `btrfs quota disable /` and it should
work.  This
ironically reiterates that one of the bigger problems with BTRFS is
that
distros are enabling unstable and known broken features by default
on
install.  I was pretty much dumbfounded when I first learned that
OpenSUSE is enabling BTRFS qgroups by default since they are known
to
not work reliably and cause all kinds of issues.


Thanks Austin! I executed the command and now I get:

btrfs qgroup show /
ERROR: can't perform the search - No such file or directory
ERROR: can't list qgroups: No such file or directory

as expected. Now I will wait for +- 1 week to see if the problem will
occur and, if not, I will send an e-mail to openSUSE factory mailing
list to start a discussion if it is better to not enable qgroups by
default.

I have a feeling that you'll probably have no issues.

As far as having qgroups enabled by default, I think the reasoning is to 
emulate having separate filesystems with their own space limits.  I can 
entirely understand this use case, and TBH it's about the only use case 
I'd consider quota groups for (per-user subvolumes for home directories 
are great, but there are numerous perfectly legitimate reasons to have 
very large amounts of data in your home directory for very short periods 
of time, so I wouldn't personally use qgroups there).  The problem 
arises from the fact that it doesn't _look_ like separate filesystems 
(single entry in df, all the mounts point at the same device, etc), and 
the standard of overloading ENOSPC to mean you've hit your quota leads 
to lots of confusion in this particular case (especially considering the 
free space issues that BTRFS is known to have from time to time).

--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Ronan Arraes Jardim Chagas]

Em Qui, 2016-09-01 às 09:21 -0400, Austin S. Hemmelgarn escreveu:
> Yes, you can just run `btrfs quota disable /` and it should
> work.  This 
> ironically reiterates that one of the bigger problems with BTRFS is
> that 
> distros are enabling unstable and known broken features by default
> on 
> install.  I was pretty much dumbfounded when I first learned that 
> OpenSUSE is enabling BTRFS qgroups by default since they are known
> to 
> not work reliably and cause all kinds of issues.

Thanks Austin! I executed the command and now I get:

btrfs qgroup show /
ERROR: can't perform the search - No such file or directory
ERROR: can't list qgroups: No such file or directory

as expected. Now I will wait for +- 1 week to see if the problem will
occur and, if not, I will send an e-mail to openSUSE factory mailing
list to start a discussion if it is better to not enable qgroups by
default.

Best regards and thanks everyone for the help,
Ronan Arraes
--
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: do not decrease bytes_may_use when replaying extents

[David Sterba]

CC Josef. It's a followup of patch that went to 4.8-rc4 so we'd better
get it to 4.8.

On Fri, Aug 26, 2016 at 11:33:14AM +0800, Wang Xiaoguang wrote:
> When replaying extents, there is no need to update bytes_may_use
> in btrfs_alloc_logged_file_extent(), otherwise it'll trigger a
> WARN_ON about bytes_may_use.
> 
> Fixes: ("btrfs: update btrfs_space_info's bytes_may_use timely")
> Signed-off-by: Wang Xiaoguang 
> ---
>  fs/btrfs/extent-tree.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index ae8f9aa..7a15990 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -8242,6 +8242,7 @@ int btrfs_alloc_logged_file_extent(struct 
> btrfs_trans_handle *trans,
>  {
>   int ret;
>   struct btrfs_block_group_cache *block_group;
> + struct btrfs_space_info *space_info;
>  
>   /*
>* Mixed block groups will exclude before processing the log so we only
> @@ -8257,9 +8258,14 @@ int btrfs_alloc_logged_file_extent(struct 
> btrfs_trans_handle *trans,
>   if (!block_group)
>   return -EINVAL;
>  
> - ret = btrfs_add_reserved_bytes(block_group, ins->offset,
> -ins->offset, 0);
> - BUG_ON(ret); /* logic error */
> + space_info = block_group->space_info;
> + spin_lock(_info->lock);
> + spin_lock(_group->lock);
> + space_info->bytes_reserved += ins->offset;
> + block_group->reserved += ins->offset;
> + spin_unlock(_group->lock);
> + spin_unlock(_info->lock);
> +
>   ret = alloc_reserved_file_extent(trans, root, 0, root_objectid,
>0, owner, offset, ins, 1);
>   btrfs_put_block_group(block_group);
> -- 
> 2.9.0
> 
> 
> 
> --
> 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
--
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] btrfsprogs: only install udev rules for udev >= 190

[David Sterba]

On Tue, Aug 30, 2016 at 09:15:44PM -0400, Jeff Mahoney wrote:
> Prior to udev v190, there was no btrfs builtin helper.  Installing it on
> systems with an older udev will cause problems.
> 
> Signed-off-by: Jeff Mahoney 

Applied, thanks.
--
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: bail out if block group has different mixed flag

[David Sterba]

On Thu, Aug 25, 2016 at 06:08:27PM -0700, Liu Bo wrote:
> Currently we allow inconsistence about mixed flag
>  (BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA).
> 
> We'd get ENOSPC if block group has mixed flag and btrfs doesn't.
> If that happens, we have one space_info with mixed flag and another
> space_info only with BTRFS_BLOCK_GROUP_METADATA, and
> global_block_rsv.space_info points to the latter one, but all bytes
> from block_group contributes to the mixed space_info, thus all the
> allocation will fail with ENOSPC.
> 
> This adds a check for the above case.
> 
> Reported-by: Vegard Nossum 
> Signed-off-by: Liu Bo 

OK for the fix. Even if we allow combining mixed and split bg, the
incompat bit must be present. This could be also part of fsck, as we
don't give an option how to fix that.
--
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: add dynamic debug support

[David Sterba]

On Wed, Aug 31, 2016 at 11:55:33PM -0400, Jeff Mahoney wrote:
> We can re-use the dynamic debugging descriptor to make use of the dynamic
> debugging mechanism but still use our own printk interface.
> 
> Defining the DEBUG macro works as it did before.  When it's defined,
> all of the messages default to print.  We can also enable all debug
> messages at boot or module-load time using the 'dyndbg' and
> 'btrfs.dyndbg' options.
> 
> Signed-off-by: Jeff Mahoney 

Reviewed-by: David Sterba 
--
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: create example debugfs file only in debugging build

[Eric Sandeen]

On 9/1/16 7:44 AM, David Sterba wrote:
> Signed-off-by: David Sterba 

Reviewed-by: Eric Sandeen 

> ---
>  fs/btrfs/sysfs.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
> index 804bd1c42e47..31f09564e170 100644
> --- a/fs/btrfs/sysfs.c
> +++ b/fs/btrfs/sysfs.c
> @@ -836,9 +836,18 @@ static int btrfs_init_debugfs(void)
>   if (!btrfs_debugfs_root_dentry)
>   return -ENOMEM;
>  
> + /*
> +  * Example code, how export data through debugfs.
> +  *
> +  * file:/sys/kernel/debug/btrfs/test
> +  * contents of: btrfs_debugfs_test
> +  */
> +#ifdef CONFIG_BTRFS_DEBUG
>   debugfs_create_u64("test", S_IRUGO | S_IWUSR, btrfs_debugfs_root_dentry,
>   _debugfs_test);
>  #endif
> +
> +#endif
>   return 0;
>  }
>  
> 

--
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Chris Murphy]

On Thu, Sep 1, 2016 at 12:51 AM, Paul Jones  wrote:
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> ow...@vger.kernel.org] On Behalf Of Chris Murphy
>> Sent: Thursday, 1 September 2016 7:59 AM
>> To: Btrfs BTRFS 
>> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local backref
>> count" messages
>>
>> This is still happening with btrfs-progs 4.7.1 and there is zero information 
>> in
>> the long result what to do about the problem, and whether it's sane to try
>> have --repair fix it, let alone what the original cause of the problem was.
>
> I just potentially damaged a perfectly good filesystem because of this. I was 
> getting hundreds of "Incorrect local backref count" so I decided to try 
> repair, which seemed to complete ok. I then rescanned without repair and 
> btrfs check eventually crashed with an assertion. That's when I figured 
> something may be wrong.

Wait, so you did a --repair and then the following-up check crashes?
But does the file system mount and does it still work? The first is
bad enough, but if it won't mount this is terrible.



-- 
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Austin S. Hemmelgarn]

On 2016-09-01 08:57, Ronan Arraes Jardim Chagas wrote:

Hi!

Em Qua, 2016-08-31 às 17:09 -0600, Chris Murphy escreveu:

OK so Ronan, I'm gonna guess the simplest work around for your
problem
is to disable quota support, and see if the problem happens again.



Look at the output of the command proposed by Jeff:

btrfs qgroup show /
qgroupid rfer excl
  
0/5  16.00KiB 16.00KiB
0/25716.00KiB 16.00KiB
0/25816.30MiB 16.30MiB
0/25911.65GiB309.67MiB
0/260 2.34MiB  2.34MiB
0/26116.00KiB 16.00KiB
0/26213.19GiB 13.19GiB
0/26316.00KiB 16.00KiB
0/26460.00KiB 60.00KiB
0/265   480.00KiB480.00KiB
0/26616.00KiB 16.00KiB
0/267 2.00GiB  2.00GiB
0/26816.00KiB 16.00KiB
0/26916.00KiB 16.00KiB
0/27016.00KiB 16.00KiB
0/27116.00KiB 16.00KiB
0/27216.00KiB 16.00KiB
0/27316.00KiB 16.00KiB
0/27416.00KiB 16.00KiB
0/275   205.78MiB205.78MiB
0/27616.00KiB 16.00KiB
0/27748.00KiB 48.00KiB
0/278   328.41MiB328.41MiB
0/283 3.92GiB 26.63MiB
0/285 3.93GiB  4.10MiB
0/294 7.84GiB100.59MiB
0/330 7.98GiB  6.61MiB
0/332 8.32GiB 69.17MiB
0/353 9.53GiB 49.46MiB
0/35510.51GiB235.39MiB
0/41511.54GiB  3.38MiB
0/41611.54GiB896.00KiB
0/41711.57GiB  2.68MiB
0/41811.57GiB160.00KiB
0/41911.54GiB  2.40MiB
0/42011.54GiB192.00KiB
0/42111.62GiB  4.61MiB
0/42211.83GiB212.93MiB
0/42711.64GiB  1.27MiB
0/42811.65GiB  4.25MiB
1/0  16.11GiB  4.77GiB
255/262  13.19GiB 13.19GiB

This system was installed with Tumbleweed ISO and I did not change
anything in btrfs options. Hence, it seems that openSUSE is enabling
quotas by default. Now, I need to disable it and avoid triggering the
problem. What is the best way I can do this? Is it OK to do just:

btrfs quota disable /

? Or do I need to format and recreate btrfs without quotas?
Yes, you can just run `btrfs quota disable /` and it should work.  This 
ironically reiterates that one of the bigger problems with BTRFS is that 
distros are enabling unstable and known broken features by default on 
install.  I was pretty much dumbfounded when I first learned that 
OpenSUSE is enabling BTRFS qgroups by default since they are known to 
not work reliably and cause all kinds of issues.



If it doesn't happen again then it sounds like the reproduce steps
are:

a. enable quota support
b. do something metadata heavy workload that's also maybe hitting
fsync; from opensuse list the example that sometimes causes it:


  osc co home:Ronis_BR/julia
  cd home:Ronis_BR/julia
  osc build --root=`pwd`/jail openSUSE_Tumbleweed x86_64

I wonder if it's easier to hit it on a hard drive, slower fsyncs?


This sounds good! Actually, I'm using a 7200RPM hard driver.


--
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: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Ronan Arraes Jardim Chagas]

Hi!

Em Qua, 2016-08-31 às 17:09 -0600, Chris Murphy escreveu:
> OK so Ronan, I'm gonna guess the simplest work around for your
> problem
> is to disable quota support, and see if the problem happens again.
> 

Look at the output of the command proposed by Jeff:

btrfs qgroup show /
qgroupid rfer excl 
   
0/5  16.00KiB 16.00KiB 
0/25716.00KiB 16.00KiB 
0/25816.30MiB 16.30MiB 
0/25911.65GiB309.67MiB 
0/260 2.34MiB  2.34MiB 
0/26116.00KiB 16.00KiB 
0/26213.19GiB 13.19GiB 
0/26316.00KiB 16.00KiB 
0/26460.00KiB 60.00KiB 
0/265   480.00KiB480.00KiB 
0/26616.00KiB 16.00KiB 
0/267 2.00GiB  2.00GiB 
0/26816.00KiB 16.00KiB 
0/26916.00KiB 16.00KiB 
0/27016.00KiB 16.00KiB 
0/27116.00KiB 16.00KiB 
0/27216.00KiB 16.00KiB 
0/27316.00KiB 16.00KiB 
0/27416.00KiB 16.00KiB 
0/275   205.78MiB205.78MiB 
0/27616.00KiB 16.00KiB 
0/27748.00KiB 48.00KiB 
0/278   328.41MiB328.41MiB 
0/283 3.92GiB 26.63MiB 
0/285 3.93GiB  4.10MiB 
0/294 7.84GiB100.59MiB 
0/330 7.98GiB  6.61MiB 
0/332 8.32GiB 69.17MiB 
0/353 9.53GiB 49.46MiB 
0/35510.51GiB235.39MiB 
0/41511.54GiB  3.38MiB 
0/41611.54GiB896.00KiB 
0/41711.57GiB  2.68MiB 
0/41811.57GiB160.00KiB 
0/41911.54GiB  2.40MiB 
0/42011.54GiB192.00KiB 
0/42111.62GiB  4.61MiB 
0/42211.83GiB212.93MiB 
0/42711.64GiB  1.27MiB 
0/42811.65GiB  4.25MiB 
1/0  16.11GiB  4.77GiB 
255/262  13.19GiB 13.19GiB 

This system was installed with Tumbleweed ISO and I did not change
anything in btrfs options. Hence, it seems that openSUSE is enabling
quotas by default. Now, I need to disable it and avoid triggering the
problem. What is the best way I can do this? Is it OK to do just:

btrfs quota disable /

? Or do I need to format and recreate btrfs without quotas?

> If it doesn't happen again then it sounds like the reproduce steps
> are:
> 
> a. enable quota support
> b. do something metadata heavy workload that's also maybe hitting
> fsync; from opensuse list the example that sometimes causes it:
> 
> 
>   osc co home:Ronis_BR/julia
>   cd home:Ronis_BR/julia
>   osc build --root=`pwd`/jail openSUSE_Tumbleweed x86_64
> 
> I wonder if it's easier to hit it on a hard drive, slower fsyncs?

This sounds good! Actually, I'm using a 7200RPM hard driver.

Thank you all very much for all the help,
Ronan Arraes
--
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

[PATCH] btrfs: create example debugfs file only in debugging build

[David Sterba]

Signed-off-by: David Sterba 
---
 fs/btrfs/sysfs.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 804bd1c42e47..31f09564e170 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -836,9 +836,18 @@ static int btrfs_init_debugfs(void)
if (!btrfs_debugfs_root_dentry)
return -ENOMEM;
 
+   /*
+* Example code, how export data through debugfs.
+*
+* file:/sys/kernel/debug/btrfs/test
+* contents of: btrfs_debugfs_test
+*/
+#ifdef CONFIG_BTRFS_DEBUG
debugfs_create_u64("test", S_IRUGO | S_IWUSR, btrfs_debugfs_root_dentry,
_debugfs_test);
 #endif
+
+#endif
return 0;
 }
 
-- 
2.7.1

--
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: remove pointless debugfs interface

[David Sterba]

On Wed, Aug 31, 2016 at 06:36:34PM -0400, Jeff Mahoney wrote:
> On 8/31/16 3:08 PM, David Sterba wrote:
> > On Wed, Aug 31, 2016 at 10:13:49AM -0500, Eric Sandeen wrote:
> >> A /sys/kernel/debug/btrfs/test file was added nearly
> >> two and a half years ago, but it serves no purpose;
> > 
> > It does. Introduced in 1bae30982bc86ab66d61ccb6e22792593b45d44d says
> > something about helping developers to easily export information from the
> > filesystem, to aid debugging. Writing the debugfs support code is not
> > obviously trivial, so it's idling in the source. Exporing a new value is
> > as easy as copy and update 3 lines of code. If you have no use for it,
> > fine.
> > 
> >> it stores and returns a value, but nothing in the btrfs
> >> code uses this value in any way.  There are no other btrfs
> >> files in this debugfs dir.
> >>
> >> This was brought to my attention because it is world-writable;
> >> it is the only such file under /sys/kernel/debug, and without
> >> knowledge of its purpose, some users were alarmed by this.
> > 
> > So let's fix the permissions.
> 
> Perhaps we can also just stick it behind a CONFIG option as well if the
> intention is to keep it around for developer debugging purposes.

So let's hide creating the 'test' file under BTRFS_DEBUG at least.
--
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 V2] btrfs: fix perms on demonstration debugfs interface

[David Sterba]

On Wed, Aug 31, 2016 at 04:49:29PM -0500, Eric Sandeen wrote:
> btrfs provides a helpful demonstration of how to export
> a global variable via debugfs; however, it is unique among
> other debugfs files in that it is world-writable, which causes
> some concern to people who are not familiar with its purpose.
> 
> Fix it so that it is only user-writable.
> 
> Signed-off-by: Eric Sandeen 

Reviewed-by: David Sterba 
--
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: remove pointless debugfs interface

[David Sterba]

On Wed, Aug 31, 2016 at 04:38:16PM -0500, Eric Sandeen wrote:
> On 8/31/16 2:08 PM, David Sterba wrote:
> > On Wed, Aug 31, 2016 at 10:13:49AM -0500, Eric Sandeen wrote:
> >> A /sys/kernel/debug/btrfs/test file was added nearly
> >> two and a half years ago, but it serves no purpose;
> > 
> > It does. Introduced in 1bae30982bc86ab66d61ccb6e22792593b45d44d says
> > something about helping developers to easily export information from the
> > filesystem, to aid debugging. Writing the debugfs support code is not
> > obviously trivial, so it's idling in the source. Exporing a new value is
> > as easy as copy and update 3 lines of code. If you have no use for it,
> > fine.
> 
> I had thought that Documentation/filesystems/debugfs.txt would suffice,
> but if you keep stuff lying around in btrfs just in case somebody needs
> to export a global variable in the future, I suppose that's cool too.  ;)

How much time would you spend coding it?  I guess more than a couple of
minutes, possibly more than once.  And not in the middle of debugging
something else.  There are more examples of code that has no apparent
user but is used for debugging.
--
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: Recommendation on raid5 drive error resolution

[Austin S. Hemmelgarn]

On 2016-08-31 19:04, Gareth Pye wrote:

ro,degraded has mounted it nicely and my rsync of the more useful data
is progressing at the speed of WiFi.

There are repeated read errors from one drive still but the rsync
hasn't bailed yet, which I think means there isn't any overlapping
errors in any of the files it has touched thus far. Am I right or is
their likely to be corrupt data in the files I've synced off?
Unless you've been running with nocow or nodatasum in your mount 
options, then what you've concluded should be correct.  I would still 
suggest verifying the data by some external means if possible, this type 
of situation is not something that's well tested, and TBH I'm amazed 
that things are working to the degree that they are.


On Wed, Aug 31, 2016 at 7:46 AM, Gareth Pye  wrote:

Or I could just once again select the right boot device in the bios. I
think I want some new hardware :)

On Wed, Aug 31, 2016 at 7:23 AM, Gareth Pye  wrote:

On Wed, Aug 31, 2016 at 4:28 AM, Chris Murphy  wrote:

But I'd try a newer kernel before you
give up on it.



Any recommendations on liveCDs that have recent kernels & btrfs tools?
For no apparent reason system isn't booting normally either, and I'm
reluctant to fix that before at least confirming the things I at least
partially care about have a recent backup.

--
Gareth Pye - blog.cerberos.id.au
Level 2 MTG Judge, Melbourne, Australia




--
Gareth Pye - blog.cerberos.id.au
Level 2 MTG Judge, Melbourne, Australia






--
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: your mail

[Austin S. Hemmelgarn]

On 2016-09-01 03:44, M G Berberich wrote:

Am Mittwoch, den 31. August schrieb Fennec Fox:

Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
2016 x86_64 GNU/Linux
btrfs-progs v4.7

Data, single: total=30.01GiB, used=18.95GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=422.17MiB
GlobalReserve, single: total=144.00MiB, used=0.00B

{02:50} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v /
[sudo] password for fennectech:
Sorry, try again.
[sudo] password for fennectech:
/: 99.8 GiB (107167244288 bytes) trimmed

{03:08} Wed Aug 31
[fennectech@Titanium ~]$  sudo fstrim -v /
[sudo] password for fennectech:
/: 99.9 GiB (107262181376 bytes) trimmed

  I ran these commands minutes after echother ane each time it is
trimming the entire free space

Anyone else seen this?   the filesystem is the root FS and is compressed


You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda296G   61G   33G  66% /

I think you're using an old kernel, this has been working since at least 
4.5, but was broken in some older releases.


--
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: [lkp] [btrfs] 18513091af: WARNING: CPU: 3 PID: 14091 at fs/btrfs/extent-tree.c:10008 btrfs_free_block_groups+0x29b/0x420 [btrfs]

[Wang Xiaoguang]

Hi,

Thanks for your report.
I've sent a patch to btrfs community to fix this issue, currently it's 
not merged.


Regards,
Xiaoguang Wang

On 09/01/2016 04:32 PM, kernel test robot wrote:

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 18513091af9483ba84328d42092bd4d42a3c958f ("btrfs: update btrfs_space_info's 
bytes_may_use timely")

in testcase: xfstests
with following parameters:

disk: 4HDD
fs: btrfs
test: generic-quick1


on test machine: qemu-system-x86_64 -enable-kvm -cpu qemu64,+ssse3 -smp 4 -m 4G

caused below changes:


+---+++
|   | 
4824f1f412 | 18513091af |
+---+++
| boot_successes| 8 
 | 0  |
| boot_failures | 0 
 | 4  |
| WARNING:at_fs/btrfs/extent-tree.c:#btrfs_free_block_groups[btrfs] | 0 
 | 4  |
+---+++



[  279.132633] BTRFS info (device dm-0): has skinny extents
[  279.242965] BTRFS info (device dm-0): checking UUID tree
[  279.522977] [ cut here ]
[  279.524657] WARNING: CPU: 3 PID: 14091 at fs/btrfs/extent-tree.c:10008 
btrfs_free_block_groups+0x29b/0x420 [btrfs]
[  279.531051] Modules linked in: dm_flakey btrfs xor raid6_pq dm_mod 
rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver sg sr_mod cdrom ata_generic 
pata_acpi snd_pcm snd_timer ata_piix snd soundcore pcspkr ppdev serio_raw 
libata floppy i2c_piix4 parport_pc parport acpi_cpufreq
[  279.550377] CPU: 3 PID: 14091 Comm: umount Not tainted 
4.7.0-rc6-00087-g1851309 #1
[  279.556229] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[  279.562315]   880124b7fcf0 8143669b 

[  279.568558]   880124b7fd30 8107d3fb 
2718
[  279.574784]  88007e965288 8800aacb4000 88007e965200 
88007e964e00
[  279.581047] Call Trace:
[  279.582259]  [] dump_stack+0x63/0x88
[  279.587003]  [] __warn+0xcb/0xf0
[  279.588640]  [] warn_slowpath_null+0x1d/0x20
[  279.593536]  [] btrfs_free_block_groups+0x29b/0x420 [btrfs]
[  279.598666]  [] close_ctree+0x192/0x370 [btrfs]
[  279.600538]  [] ? evict_inodes+0x189/0x1a0
[  279.605395]  [] btrfs_put_super+0x19/0x20 [btrfs]
[  279.610339]  [] generic_shutdown_super+0x6f/0x100
[  279.612236]  [] kill_anon_super+0x12/0x20
[  279.617083]  [] btrfs_kill_super+0x18/0x110 [btrfs]
[  279.622070]  [] deactivate_locked_super+0x43/0x70
[  279.623980]  [] deactivate_super+0x5a/0x60
[  279.628770]  [] cleanup_mnt+0x3f/0x90
[  279.630304]  [] __cleanup_mnt+0x12/0x20
[  279.634894]  [] task_work_run+0x88/0xc0
[  279.636419]  [] exit_to_usermode_loop+0xc2/0xd0
[  279.638171]  [] syscall_return_slowpath+0xa1/0xb0
[  279.639841]  [] entry_SYSCALL_64_fastpath+0xa2/0xa4
[  279.658835] ---[ end trace 4976d490d5aef958 ]---
[  279.660401] BTRFS: space_info 1 has 8126464 free, is not full



To reproduce:

 git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
 cd lkp-tests
 bin/lkp install job.yaml  # job file is attached in this email
 bin/lkp run job.yaml



Thanks,
Xiaolong






--
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: your mail

[M G Berberich]

Am Mittwoch, den 31. August schrieb Fennec Fox:
> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> 2016 x86_64 GNU/Linux
> btrfs-progs v4.7
> 
> Data, single: total=30.01GiB, used=18.95GiB
> System, single: total=4.00MiB, used=16.00KiB
> Metadata, single: total=1.01GiB, used=422.17MiB
> GlobalReserve, single: total=144.00MiB, used=0.00B
> 
> {02:50} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> Sorry, try again.
> [sudo] password for fennectech:
> /: 99.8 GiB (107167244288 bytes) trimmed
> 
> {03:08} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> /: 99.9 GiB (107262181376 bytes) trimmed
> 
>   I ran these commands minutes after echother ane each time it is
> trimming the entire free space
> 
> Anyone else seen this?   the filesystem is the root FS and is compressed

You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda296G   61G   33G  66% /


MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 
--
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: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[Paul Jones]

> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Chris Murphy
> Sent: Thursday, 1 September 2016 7:59 AM
> To: Btrfs BTRFS 
> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local backref
> count" messages
> 
> This is still happening with btrfs-progs 4.7.1 and there is zero information 
> in
> the long result what to do about the problem, and whether it's sane to try
> have --repair fix it, let alone what the original cause of the problem was.

I just potentially damaged a perfectly good filesystem because of this. I was 
getting hundreds of "Incorrect local backref count" so I decided to try repair, 
which seemed to complete ok. I then rescanned without repair and btrfs check 
eventually crashed with an assertion. That's when I figured something may be 
wrong.

Thankfully I have an offsite backup (this was the onsite backup), but what a 
pain

Paul.