BTRFS info (device dm-1): found 1 extents


Recommended Posts

That's not an error, and it's normal during a balance, which apparently was run before:

 

Nov 25 04:30:11 Veyron kernel: BTRFS info (device dm-1): relocating block group 177222975488 flags data|raid1
Nov 25 04:30:12 Veyron kernel: BTRFS info (device dm-1): found 295 extents
### [PREVIOUS LINE REPEATED 1 TIMES] ###
Nov 25 04:30:12 Veyron kernel: BTRFS info (device dm-1): relocating block group 176149233664 flags data|raid1
Nov 25 04:30:13 Veyron kernel: BTRFS info (device dm-1): found 3586 extents
### [PREVIOUS LINE REPEATED 1 TIMES] ###
Nov 25 04:30:14 Veyron kernel: BTRFS info (device dm-1): found 1 extents
### [PREVIOUS LINE REPEATED 97 TIMES] ###
Nov 25 04:30:18 Veyron kernel: btrfs_printk: 40 callbacks suppressed
Nov 25 04:30:18 Veyron kernel: BTRFS info (device dm-1): found 1 extents
### [PREVIOUS LINE REPEATED 972 TIMES] ###
Nov 25 04:31:19 Veyron kernel: btrfs_printk: 21 callbacks suppressed
Nov 25 04:31:19 Veyron kernel: BTRFS info (device dm-1): found 1 extents

 

but not so normal to keep repeating that for so long, assuming no balance is running now reboot to see if it goes away.

 

P.S. lots of call traces mentioning macvlan, these are usually caused by dockers with custom IPs.

Link to comment

Had to force the reboot. Still came back up with the extent messages. Did a btrfsck --repair and that seemed to resolve it. I'm not feeling very comfortable with btrfs since this is the second major issue I've had with it in less than 30 days, are other file systems still available for cache drives?

 

I guess the custom IPs on dockers are a no no? Is there a better way of accomplishing this? I really need them for filtering VPN traffic but maybe I can setup another virtual network for these purposes? 

 

 

Link to comment

 

1 minute ago, itimpi said:

If you have a single cache drive then XFS is an option.   If you have multiple drives (I.e. a cache pool) then BTRFS is the only option.

 

Yeah, I have two cache drives (mirroring each other for redundancy) but I'm questioning the usefulness of this since it didn't do me any good after last months failure and ended up going back to a nightly backup anyway.

Link to comment
On 11/26/2018 at 5:42 PM, johnnie.black said:

btrfs is not the stablest of filesystems, but if you keep getting issues there are likely underlying hardware issues, I use btrfs an all my Unraid servers, including all data disks, for years now without any issues.

 

 

Ok, that's good info to have, I'll direct my focus on hardware and other things to find the source of these problems then. I don't think it's a hardware issue, but this macvlan trace calls stuff got my attention, somehow I was overlooking in the logs, so thanks for pointing it out. I'm leaning more towards the macvlan trace calls causing something like this continuous extent problem where the logs filled my available drive space and then caused subsequent failures. Digging through this forum, I believe the I found the original bug report where the OP mentioned this issue starting with pihole. It seems most if not all of my call traces are also related to the pihole docker container. Ditching the pihole container and reducing the number of static IPs as much as possible seems to have resolved my issues. Knock on wood, I still have a handful of static IP container but I haven't seen a call trace in almost 2 days.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.