[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: btrfs-transacti hangs system for several seconds every few minutes
From:       Qu Wenruo <quwenruo.btrfs () gmx ! com>
Date:       2020-03-29 13:14:40
Message-ID: 38a47c1a-d5b1-43c5-e026-10c2d4a9c039 () gmx ! com
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 2020/3/29 下午12:03, Brad Templeton wrote:
> Not using qgroups.  Not doing snapshots.    Did a reboot with the
> options to upgrade to v2 -- it failed,

What did you mean about "it failed"

It failed to mount or something else showed up?

If failed to mount, would you like to shared the dmesg of that mount
failure?

> in that the disk check took more
> than 6 minutes,

Please be aware that, btrfs check, unlike e2fsck, will always check all
metadata of the fs, no matter if the fs is clean unmounted or not.

In fact, btrfs unlike other journal based fs, has no clear way to
determine if an fs is unmounted cleanly or not.
(Log tree is one method, but not a reliable one).

6 min looks completely valid to me.

> but it worked, and the second time I was able to boot,
> and -- knock on wood -- so far it has not hung.

If you hit the hang, you could try to use 'perf' command to try to probe
the runtime of btrfs_commit_transaction() and its major components.

It would be super helpful if we could determine which is the major cause.

> 
> I wonder why they put 5.3.0 as the standard advanced Kernel in Ubuntu
> LTS if it has a data corruption bug.   I don't know if I've seen any
> release of 5.4.14 in a PPA yet -- manual kernel install is such a pain
> the few times I have done it.  I could revert, but the reason I switched
> to 5.3, not long ago, was another problem with sound drivers.
> 
> BTW, even though it now works, it still takes 90 seconds every boot
> doing a disk check, even after what I think is a clean shutdown.   I
> presume that is not normal, any clues on what may cause that?
> 
Another thing I found is, in your initial report, your swap is heavily used.

I guess it may be related to the memory pressure, where every metadata
write needs to do a lot of metadata read before it can do anything.

If that's the case, it would be good to keep an eye on the memory
pressure to make sure fs can still have enough metadata cache without
triggering too much IO in its critical section.

Thanks,
Qu


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]