On Mon, Oct 21, 2019 at 12:58:12PM +0200, Patrik Lundquist wrote:
> I'm running Debian Testing with kernel 5.2.17-1. Five disk raid1 with
> at least 393.01GiB unallocated on each disk. No device errors. No
> kernel WARNINGs or ERRORs.
> 
> BTRFS info (device dm-1): enabling auto defrag
> BTRFS info (device dm-1): using free space tree
> BTRFS info (device dm-1): has skinny extents
> 
> Mounted with 
> noauto,noatime,autodefrag,skip_balance,space_cache=v2,enospc_debug.
> 
> First btrfs_dump_space_info() is
> 
> BTRFS info (device dm-1): space_info 4 has 18446744073353838592 free,
> is not full
> BTRFS info (device dm-1): space_info total=10737418240,
> used=9636544512, pinned=0, reserved=27066368, may_use=1429454848,
> readonly=65536
> BTRFS info (device dm-1): global_block_rsv: size 536870912 reserved 536870912
> BTRFS info (device dm-1): trans_block_rsv: size 0 reserved 0
> BTRFS info (device dm-1): chunk_block_rsv: size 0 reserved 0
> BTRFS info (device dm-1): delayed_block_rsv: size 20185088 reserved 20185088
> BTRFS info (device dm-1): delayed_refs_rsv: size 868745216 reserved 868745216
> 
> and current last is
> 
> BTRFS info (device dm-1): space_info 4 has 0 free, is not full
> BTRFS info (device dm-1): space_info total=10737418240,
> used=9664561152, pinned=458752, reserved=2523136, may_use=1069809664,
> readonly=65536
> BTRFS info (device dm-1): global_block_rsv: size 536870912 reserved 536821760
> BTRFS info (device dm-1): trans_block_rsv: size 0 reserved 0
> BTRFS info (device dm-1): chunk_block_rsv: size 0 reserved 0
> BTRFS info (device dm-1): delayed_block_rsv: size 0 reserved 0
> BTRFS info (device dm-1): delayed_refs_rsv: size 556531712 reserved 498647040
> 
> with lots more in between and no other Btrfs kernel printing preceding
> it since mounting.
> 
> It's the first time I'm seeing it but I have always mounted with
> enospc_debug since it always seems too late to add the option when you
> finally need it.
> 
> What does it mean? Should I be worried? What to do? No apparent problems yet.

enospc_debug is known to be noisy, in many cases it prints the state of
the space management structures at some interesting points. It's
possible that the amount of the information dumped changes over time,
there have been updates to the space reservations and related code.

I've checked the message levels of the messages printed under the
option, some of them are 'debug' some of them are 'info'. I would be
possible to make them all 'debug' so they are in the log but you can
filter them out on console.

Reply via email to