First of all, thanks for the response - and if my mails are somehow
off-topic for the list, also feelf ree to tell me :)
On Fri, Feb 14, 2020 at 01:57:33PM +0200, Nikolay Borisov <nborisov@xxxxxxxx> wrote:
> > one core) in top:
>
> So this is a 50tb useful space, right?
Yup, pretty full, too. I also forgot to mention that the vast majority
of files are between 400kB and 2MB, and not, as one might expect from
textgroups, a few kilobytes.
> > [<0>] tree_search_offset.isra.0+0x16a/0x1d0 [btrfs]
>
> This points to freespace cache. One thing that I might suggest is try
Hmm, I did switch to the free space tree on all larger filesystems long
ago, or at least I thought so. I use these mount options on the fs in
question:
rw,noatime,nossd,space_cache=v2,commit=120,subvolid=5,subvol=/
I assume this is the correct way to get it (and your space_cache=2 is a
typo, or an alternative?).
So either I am not switching on the free space tree properly, or it's not
the problem. I did notice major speedups form it in the past, though.
> So you can't deduce that the free space cache is being used, and
> despite being the default, it was not mentioned by Marc if he's not
> using already the free space tree (-o space_cache=v2).
Yes, sorry, it's alwayss hard to strike a balance between needed info and
too much.
> Switching from one to the other might make the problem go away, simply
> because it cause free space to be scanned and build a new cache or
> tree.
So clearing the free space tree might also help? Can I do this while its
mounted using remount or do I haver to umount/mount (or use btrfs check)?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@xxxxxxxxxx
-=====/_/_//_/\_,_/ /_/\_\
