On 8/10/18 5:39 PM, Dan Merillat wrote: > On Fri, Aug 10, 2018 at 5:13 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >> >> >> On 8/10/18 4:47 PM, Dan Merillat wrote: >>> Unfortunately that doesn't appear to be it, a forced restart and >>> attempted to mount with skip_balance leads to the same thing. >> >> That's strange. >> >> Would you please provide the following output to determine whether we >> have any balance running? >> >> # btrfs inspect dump-super -fFa <device> [snip]
Nothing special for super dump.
>
>>
>> # btrfs inspect dump-tree -t root <device>
>>
>
> Too large to include inline, hopefully attaching works.
Although not sure about the details, but the fs looks pretty huge.
Tons of subvolume and its free space cache inodes.
But only 3 tree reloc trees, unless you have tons of reflinked files
(off-line deduped), it shouldn't cause a lot of problem.
At least, we have some progress dropping tree reloc tree for subvolume 6482.
If you check the dump-tree output for the following data, the "drop key"
should change during mount: (inspect dump-tree can be run mounted)
item 175 key (TREE_RELOC ROOT_ITEM 6482) itemoff 8271 itemsize 439
<snip>
drop key (2769795 EXTENT_DATA 12665933824) level 2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So for the worst case scenario, there is some way to determine whether
it's processing.
And according to the level (3), which is not small for each subvolume, I
doubt that's the reason why it's so slow.
BTW, for last skip_balance mount, is there any kernel message like
"balance: resume skipped"?
Have you tried mount the fs readonly with skip_balance? And then remount
rw, still with skip_balance?
>
> I think there's a balance though:
> item 178 key (BALANCE TEMPORARY_ITEM 0) itemoff 6945 itemsize 448
> temporary item objectid BALANCE offset 0
> balance status flags 6
> DATA
> profiles 0 devid 0 target 0 flags 0
> usage_min 0 usage_max 0 pstart 0 pend 0
> vstart 0 vend 0 limit_min 0 limit_max 0
> stripes_min 0 stripes_max 0
> METADATA
> profiles 0 devid 0 target 0 flags 0
> usage_min 0 usage_max 0 pstart 0 pend 0
> vstart 0 vend 0 limit_min 0 limit_max 0
> stripes_min 0 stripes_max 0
> SYSTEM
> profiles 0 devid 0 target 0 flags 0
> usage_min 0 usage_max 0 pstart 0 pend 0
> vstart 0 vend 0 limit_min 0 limit_max 0
> stripes_min 0 stripes_max 0
>
> btrfs check is still running, it's found one thing so far:
>
> Checking filesystem on /dev/bcache0
> UUID: 16adc029-64c5-45ff-8114-e2f5b2f2d331
> checking extents
> ref mismatch on [13135707160576 16384] extent item 0, found 1
> tree backref 13135707160576 parent 13136850550784 root 13136850550784 not
> found
> in extent tree
> backpointer mismatch on [13135707160576 16384]
Just single error, not bad (compared to some catastrophic error).
It may be a false alert since it's a backref for reloc tree, which is
not that common for us to test.
So the fs should be OK to go, just need to figure out how and why
skip_balance is not working.
Thanks,
Qu
> ERROR: errors found in extent allocation tree or chunk allocation
> checking free space cache
> checking fs roots
>
signature.asc
Description: OpenPGP digital signature
