On 08/08/2016 05:24 PM, Chris Mason wrote:
> On 08/08/2016 10:21 AM, Nikolay Borisov wrote:
>>
>>
>> On 08/08/2016 05:16 PM, Chris Mason wrote:
>>>
>>> Fantastic, thanks again for digging through it. Making the patch is
>>> much easier than testing the patch in this case. If you can trigger
>>>
On 08/08/2016 10:21 AM, Nikolay Borisov wrote:
On 08/08/2016 05:16 PM, Chris Mason wrote:
Fantastic, thanks again for digging through it. Making the patch is
much easier than testing the patch in this case. If you can trigger
this semi-reliably, we can add some debugging to make sure we're
On 08/08/2016 05:16 PM, Chris Mason wrote:
>
> Fantastic, thanks again for digging through it. Making the patch is
> much easier than testing the patch in this case. If you can trigger
> this semi-reliably, we can add some debugging to make sure we're not
> papering over some other problem.
I
On 08/08/2016 06:49 AM, Nikolay Borisov wrote:
On 08/05/2016 06:12 PM, Chris Mason wrote:
Hello Chris,
Indeed it seems that btrfs_uuid_iter_rem returned a ENOENT:
callq 0xa081f450
mov%eax,%r13d
je 0xa081f882 ; if uuid_iter_rem
returned -ENOENT; else fall through
On 08/05/2016 06:12 PM, Chris Mason wrote:
>
> On 08/05/2016 07:08 AM, Nikolay Borisov wrote:
>> Hello,
>>
>> Recently I started getting the following crashes on some servers,
>> running btrfs:
>>
>> [340435.480338] BTRFS info (device loop7): disk space caching is enabled
>> [340435.480509] BTRF
On Fri, Aug 5, 2016 at 6:12 PM, Chris Mason wrote:
>
> On 08/05/2016 07:08 AM, Nikolay Borisov wrote:
>> Hello,
>>
>> Any ideas how come btrfs_path can be all zero, the one in
>> the first slot comes from the increment in btrfs_next_old_item.
>
> Thanks for all the extra details. It really must b
On 08/05/2016 07:08 AM, Nikolay Borisov wrote:
> Hello,
>
> Recently I started getting the following crashes on some servers,
> running btrfs:
>
> [340435.480338] BTRFS info (device loop7): disk space caching is enabled
> [340435.480509] BTRFS: has skinny extents
> [340441.716174] BTRFS: checking
