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> # btrfs inspect dump-tree -t root <device> > > 20 minutes in btrfs-transactio had a large burst of reads then started > spinning the CPU with the disk idle. > > Is this recoverable? I could leave it for a day or so if it may make > progress, but if not I'd like to start on other options. When umounted, would you please also try "btrfs check --readonly <device>" to see if there is anything wrong about the fs? Thanks, Qu > > On Fri, Aug 10, 2018 at 3:59 AM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >> >> >> On 8/10/18 3:40 PM, Dan Merillat wrote: >>> Kernel 4.17.9, 11tb BTRFS device (md-backed, not btrfs raid) >>> >>> I was testing something out and enabled quota groups and started getting >>> 2-5 minute long pauses where a btrfs-transaction thread spun at 100%. >> >> Looks pretty like a running balance and quota. >> >> Would you please try with balance disabled (temporarily) with >> skip_balance mount option to see if it works. >> >> If it works, then either try resume balance, or just cancel the balance. >> >> Nowadays balance is not needed routinely, especially when you still have >> unallocated space and enabled quota. >> >> Thanks, >> Qu >> >>> >>> Post-reboot the mount process spinds at 100% CPU, occasinally yielding >>> to a btrfs-transaction thread at 100% CPU. The switchover is marked >>> by a burst of disk activity in btrace. >>> >>> Btrace shows all disk activity is returning promptly - no hanging submits. >>> >>> Currently the mount is at 6+ hours. >>> >>> Suggestions on how to go about debugging this? >>> >>
Attachment:
signature.asc
Description: OpenPGP digital signature
