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.
signature.asc
Description: Digital signature
