Am Freitag, 23. Januar 2015, 18:29:40 schrieb Zygo Blaxell:
> On Fri, Jan 23, 2015 at 03:01:28PM +0100, Martin Steigerwald wrote:
> > Hi!
> > 
> > Anyone seen this?
> > 
> > Reported as:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=91911
> 
> I have seen something like this since 3.15.
> 
> I've also seen its cousin, which gets stuck in evict_inode, but the
> stacks of the hanging processes start from renameat2() instead of
> unlinkat(). I haven't seen the renameat2() variant of this bug since
> 3.18-rc6.

I see.

Well than it is at least not only happening here. So we have some more 
BTRFS getting stuck issues. And this hangs happened here with BTRFS still 
being able to allocate some hungs and there is also no kworker kthread at 
100% of one core, so this is a different issue.

> > I just want to get rid of some 127000+ akonadi lost+found files, any
> > delete command I start just gets rid of some thousands and then
> > hangs.

> > merkaba:~> btrfs fi df /home
> > Data, RAID1: total=160.92GiB, used=111.09GiB
> > System, RAID1: total=32.00MiB, used=48.00KiB
> > Metadata, RAID1: total=5.99GiB, used=2.49GiB
> > GlobalReserve, single: total=512.00MiB, used=0.00B
> > merkaba:~> btrfs fi sh /home
> > Label: 'home'  uuid: […]

> >         Total devices 2 FS bytes used 113.58GiB
> >         devid    1 size 170.00GiB used 166.94GiB path
> >         /dev/mapper/msata-home
> >         devid    2 size 170.00GiB used 166.94GiB path
> >         /dev/mapper/sata-home

> > Btrfs v3.18

Also there is a lot of free space inside the allocated chunks.

[… description + dmesg as in bug report linked above …]
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7