ling btrfs with "dd if=/dev/zero
>>>> of=dummyfile.dat",
>>>> only data chunks are allocated but no metadata ones. So, how does the
>>>> metadata_ratio
>>>> option really work?
>>>>
>>>> Note that I'm trying
Dne 10.3.2018 v 15:51 Martin Svec napsal(a):
> Dne 10.3.2018 v 13:13 Nikolay Borisov napsal(a):
>>
>>
> And then report back on the output of the extra debug
> statements.
>
> Your global rsv is essentially unused, this means
> in the worst case the code should fallback to u
Dne 10.3.2018 v 13:13 Nikolay Borisov napsal(a):
>
>
>
And then report back on the output of the extra debug
statements.
Your global rsv is essentially unused, this means
in the worst case the code should fallback to using the global rsv
for satisfying the memory a
>>> And then report back on the output of the extra debug
>>> statements.
>>>
>>> Your global rsv is essentially unused, this means
>>> in the worst case the code should fallback to using the global rsv
>>> for satisfying the memory allocation for delayed refs. So we should
>>> figure out wh
Dne 9.3.2018 v 20:03 Martin Svec napsal(a):
> Dne 9.3.2018 v 17:36 Nikolay Borisov napsal(a):
>> On 23.02.2018 16:28, Martin Svec wrote:
>>> Hello,
>>>
>>> we have a btrfs-based backup system using btrfs snapshots and rsync.
>>> Sometimes,
>>> we hit ENOSPC bug and the filesystem is remounted read
On 9.03.2018 21:03, Martin Svec wrote:
> Being curious, how do you know that my global rsv is almost unused? During
> backups, I see that
> the usage is sometimes very close to the 512 MiB limit. I tried to increase
> the limit to 1 GiB but it
> didn't help.
Well according to your output:
Gl
Dne 9.3.2018 v 17:36 Nikolay Borisov napsal(a):
>
> On 23.02.2018 16:28, Martin Svec wrote:
>> Hello,
>>
>> we have a btrfs-based backup system using btrfs snapshots and rsync.
>> Sometimes,
>> we hit ENOSPC bug and the filesystem is remounted read-only. However,
>> there's
>> still plenty of un
On 23.02.2018 16:28, Martin Svec wrote:
> Hello,
>
> we have a btrfs-based backup system using btrfs snapshots and rsync.
> Sometimes,
> we hit ENOSPC bug and the filesystem is remounted read-only. However, there's
> still plenty of unallocated space according to "btrfs fi usage". So I think
On 9.03.2018 17:04, Martin Svec wrote:
> Nobody knows?
>
> I'm particularly interested why debug space_info 4 shows negative (unsigned
> 18446744072120172544)
> value as free metadata space, please see the original report. Is it a bug in
> dump_space_info(), or
> metadata reservations can tem
Nobody knows?
I'm particularly interested why debug space_info 4 shows negative (unsigned
18446744072120172544)
value as free metadata space, please see the original report. Is it a bug in
dump_space_info(), or
metadata reservations can temporarily exceed the total space, or is it an
indication
Hello,
we have a btrfs-based backup system using btrfs snapshots and rsync. Sometimes,
we hit ENOSPC bug and the filesystem is remounted read-only. However, there's
still plenty of unallocated space according to "btrfs fi usage". So I think this
isn't another edge condition when btrfs runs out of
11 matches
Mail list logo