Re: BTRFS free space handling still needs more work: Hangs again (no complete lockups, "just" tasks stuck for some time)

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote:
> My simple test case didn´t trigger it, and I so not have another twice 160
> GiB available on this SSDs available to try with a copy of my home
> filesystem. Then I could safely test without bringing the desktop session to
> an halt. Maybe someone has an idea on how to "enhance" my test case in
> order to reliably trigger the issue.
> 
> It may be challenging tough. My /home is quite a filesystem. It has a maildir
> with at least one million of files (yeah, I am performance testing KMail and
> Akonadi as well to the limit!), and it has git repos and this one VM image,
> and the desktop search and the Akonadi database. In other words: It has
> been hit nicely with various mostly random I think workloads over the last
> about six months. I bet its not that easy to simulate that. Maybe some runs
> of compilebench to age the filesystem before the fio test?
> 
> That said, BTRFS performs a lot better. The complete lockups without any
> CPU usage of 3.15 and 3.16 have gone for sure. Thats wonderful. But there
> is this kworker issue now. I noticed it that gravely just while trying to
> complete this tax returns stuff with the Windows XP VM. Otherwise it may
> have happened, I have seen some backtraces in kern.log, but it didn´t last
> for minutes. So this indeed is of less severity than the full lockups with
> 3.15 and 3.16.
> 
> Zygo, was is the characteristics of your filesystem. Do you use
> compress=lzo and skinny metadata as well? How are the chunks allocated?
> What kind of data you have on it?

compress-force (default zlib), no skinny-metadata.  Chunks are d=single,
m=dup.  Data is a mix of various desktop applications, most active
file sizes from a few hundred K to a few MB, maybe 300k-400k files.
No database or VM workloads.  Filesystem is 100GB and is usually between
98 and 99% full (about 1-2GB free).

I have another filesystem which has similar problems when it's 99.99%
full (it's 13TB, so 0.01% is 1.3GB).  That filesystem is RAID1 with
skinny-metadata and no-holes.

On various filesystems I have the above CPU-burning problem, a bunch of
irreproducible random crashes, and a hang with a kernel stack that goes
through SyS_unlinkat and btrfs_evict_inode.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]