Re: Rough (re)start with btrfs

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1506 bytes --]



On 2019/5/3 下午1:41, Hendrik Friedel wrote:
> Hello,
> 
> -by the way: I think my mail did not appear in the list, but only
> reached Chris and Qu directly. I just tried to re-send it. Could this be
> caused by
> 1) me not a subscriber of the list
> 2) combined with me sending attachments
> I did *not* get any error message by the server.
> 
>>>  I was tempted to ask, whether this should be fixed. On the other
>>> hand, I
>>>  am not even sure anything bad happened (except, well, the system -at
>>>  least the copy- seemed to hang).
>>
>> Definitely needs to be fixed.
>>
>> With full dmesg, it's now clear that is a real dead lock.
>> Something wrong with the free space cache, blocking the whole fs to be
>> committed.
>>
> So, what's the next step? Shall I open a bug report somewhere, or is it
> already on some list?

Not sure if other is looking into this.

Btrfs bug tracking is somewhat tricky.
Some prefer bug report in mail list directly like me, some prefer kernel
bugzilla.

> 
>> If you still want to try btrfs, you could try "nosapce_cache" mount
>> option.
>> Free space cache of btrfs is just an optimization, you can completely
>> ignore that with minor performance drop.
>>
> I will try that, yes.
> Can you confirm, that it is unlikely, that I lost any data / damaged the
> Filesystem?

You lost nothing except the new data which is going be committed in the
blocked transaction.

Thanks,
Qu

> 
> Regards,
> Hendrik
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]