Hi all,
Dne 20.01.2021 v 0:12 Zygo Blaxell napsal(a):
> With the 4 device types we can trivially specify this arrangement.
>
> The sorted device lists would be:
>
> Metadata sort order Data sort order
> metadata only (3) data only (2)
> metadata pr
Hello Chris,
Dne 7.5.2018 v 18:37 Chris Mason napsal(a):
>
>
> On 7 May 2018, at 12:16, Martin Svec wrote:
>
>> Hello Chris,
>>
>> Dne 7.5.2018 v 16:49 Chris Mason napsal(a):
>>> On 7 May 2018, at 7:40, Martin Svec wrote:
>>>
>>>
Hello Chris,
Dne 7.5.2018 v 16:49 Chris Mason napsal(a):
> On 7 May 2018, at 7:40, Martin Svec wrote:
>
>> Hi,
>>
>> According to man btrfs [1], I assume that metadata_ratio=1 mount option
>> should
>> force allocation of one metadata chunk after every alloca
Hi,
According to man btrfs [1], I assume that metadata_ratio=1 mount option should
force allocation of one metadata chunk after every allocated data chunk.
However,
when I set this option and start filling btrfs with "dd if=/dev/zero
of=dummyfile.dat",
only data chunks are allocated but no metad
Hi David,
this looks like the bug that I already reported two times:
https://www.spinics.net/lists/linux-btrfs/msg54394.html
https://www.spinics.net/lists/linux-btrfs/msg75104.html
The second thread contains Nikolay's debug patch that can confirm if you run
out of global metadata
reservations t
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 essentia
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
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,
>>
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. Howe
it an
indication of a damaged
filesystem? Also note that rebuilding free space cache doesn't help.
Thank you.
Martin
Dne 23.2.2018 v 15:28 Martin Svec napsal(a):
> Hello,
>
> we have a btrfs-based backup system using btrfs snapshots and rsync.
> Sometimes,
> we hit ENOSPC bug and th
] BTRFS info (device sdb): forced readonly
[285169.096979] BTRFS warning (device sdb): Skipping commit of aborted
transaction.
[285169.096981] BTRFS: error (device sdb) in cleanup_transaction:1873:
errno=-28 No space left
How can I help you to fix this issue?
Regards,
Martin Svec
--
To un
Dne 22.4.2016 v 23:00 Nicholas D Steeves napsal(a):
> On 21 April 2016 at 18:44, Chris Murphy wrote:
>> On Thu, Apr 21, 2016 at 6:53 AM, Martin Svec wrote:
>>> Hello,
>>>
>>> we use btrfs subvolumes for rsync-based backups. During backups btrfs often
>>
Dne 22.4.2016 v 0:44 Chris Murphy napsal(a):
> On Thu, Apr 21, 2016 at 6:53 AM, Martin Svec wrote:
>> Hello,
>>
>> we use btrfs subvolumes for rsync-based backups. During backups btrfs often
>> fails with "No space
>> left" error and goes to readonly
ted multiple times:
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg48061.html
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg47355.html
Best regards
Martin Svec
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a messag
14 matches
Mail list logo
