Re: Frozen transaction

[Olivier Bonvalet <btrfs.list@daevel.fr>]

Thanks for your reply.

On 09/10/2012 11:52, David Sterba wrote:
> On Tue, Oct 09, 2012 at 09:37:48AM +0200, Olivier Bonvalet wrote:
>> on one system I have a "frozen transaction" since more than 24 hours,
>> without any IO.
>> I can't umount the partition, delete a snapshot or write anything.
>> I try to reboot the system, but the problem is still present.
>
> The processes could point at the cleaner deadlock, though I'm not
> completely sure without looking at the process stacks (/proc/PID/stack).

I didn't see any "stack" entry in /proc/$PID/ ; I will try to find which 
kernel option export that.


>
> If the problem persists accross reboots, how long after mount does it
> take to get to this state? Cleaner usually kicks in after the 30 second
> transaction commit period, so this should be easy to verify if it's
> immediate or if it requires some load to get into the dead state.

The cleaner process get it's state D between 30 and 60 seconds after the 
reboot. But that cleaner process should not throw a lot of write access ?

This time I tried to remount with the space-cache enabled, there is a 
lot of read access now. Does that space cache will help to find "free 
locations" ?


>
>> The partition is mounted with this options :
>> # mount | grep btrfs
>> /dev/mapper/vg--sofia-backup on /backup type btrfs
>> (rw,noatime,compress-force=zlib,nossd)
>
> So you don't mount with autodefrag, hmm. The deadlock I had in mind
> is more likely with autodefrag but also requires umount.
>
>> The disk is near full :
>> # btrfs fi df /backup/
>> Data: total=482.68GB, used=480.89GB
>
> Quite full.

Yes, it's the problem.


>
>> System, DUP: total=32.00MB, used=72.00KB
>> System: total=4.00MB, used=0.00
>> Metadata, DUP: total=10.12GB, used=8.82GB
>>
>> But one of the last actions was the removing of some big subvolumes (near
>> 50GB).
>
> Given the amount of free space left, this creates high pressure on data
> writes and makes the deadlock more likely.
>
>> There is no error in logs, the frozen transaction was started from a 3.5*
>> kernel (from GIT), and the system is now running on a 3.6.1 kernel
>> (vanilla).
>>
>> Is there something I can do to solve that problem ?
>
> No, there's a patch sent out in order to fix the deadlocks but it's
> unfortunatelly still unmerged.
>
>

I suppose I can't resize the FS without solving that cleanup deadlock 
before ?


> david
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>