On 8/11/18 6:14 AM, James Courtier-Dutton wrote: > On 6 August 2018 at 07:26, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >> >> >>> WARNING: CPU: 3 PID: 803 at >>> /build/linux-hwe-SYRsgd/linux-hwe-4.15.0/fs/btrfs/extent_map.c:77 >>> free_extent_map+0x78/0x90 [btrfs] >> >> Then it makes sense, as it's a WARN_ON() line, showing one extent map is >> still used. >> >> If it get freed, it will definitely cause some rbtree corruption. >> >> >> It's should be the only free_extent_map() call in __do_readpage() function. >> However a first glance into this function shows nothing wrong, nor new >> modification in this function. >> (Maybe it's the get_extent() hook?) >> >> Is there any reproducer? Or special workload? > The workload is fairly simple. > 1) The server is receiving 1Gbyte files from across the network, in 10 > minute intervals, and storing them on the HDD. > 2) A process reads the files, scanning them for certain patterns. > 3) A cron job deletes the old files.
This looks pretty normal. Shouldn't cause any problem. > > > >> >> And, have you tried "btrfs check --readonly <device>"? If there is any >> error it would help a lot to locate the problem. >> > root@sandisk:~# btrfs check --readonly /dev/sda3 > Checking filesystem on /dev/sda3 > UUID: 8c9063b9-a4bb-48d1-92ba-6adf49af6fb5 > checking extents > checking free space cache > block group 6874953940992 has wrong amount of free space > failed to load free space cache for block group 6874953940992 This problem can be solved by "btrfs check --clear-space-cache=v1". Normally it shouldn't cause much problem. > checking fs roots > checking csums > checking root refs > found 1488143566396 bytes used err is 0 > total csum bytes: 1448276084 > total tree bytes: 5079711744 > total fs tree bytes: 3280207872 > total extent tree bytes: 146997248 > btree space waste bytes: 1100557047 > file data blocks allocated: 2266345996288 > referenced 2235075653632 > root@sandisk:~# > > > So, not much to see there. > Any more ideas? Not really. If it's still reproducible, maybe it's worth trying the latest upstream kernel. Thanks, Qu >
signature.asc
Description: OpenPGP digital signature
