Re: BTRFS: Transaction aborted (error -24)

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

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



On 2020/6/19 下午12:04, Greed Rong wrote:
> I have restarted the delete service. And unfortunately it happened again.
> I am confuse that:
>     1. When will an anon bdev be allocated in btrfs?

When a new subvolume is created, or one existing subvolume get read for
its first time after mount.

>     2. When will an anon bdev return to the pool?

When a subvolume is unlinked (with the latest patch), or when a
subvolume is completely deleted (current behavior), or when the whole
btrfs is unmounted.


>     3. Are there any tools to find out how many subvolumes have been
> deleted but not committed?

I'm not sure, but you can always wait for all orphan subvolumes to be
completely deleted, by using "btrfs sub sync" command.

Thanks,
Qu

> 
> Thanks
> 
> On Thu, Jun 18, 2020 at 8:34 PM David Sterba <dsterba@suse.cz> wrote:
>>
>> On Mon, Jun 15, 2020 at 08:50:28PM +0800, Greed Rong wrote:
>>> Does that mean about 2^20 subvolumes can be created in one root btrfs?
>>
>> No, subvolume ids are assigned incrementally, the amount is 2^64 so this
>> shouldn't be a problem in practice.
>>
>>> The snapshot delete service was stopped a few weeks ago. I think this
>>> is the reason why the id pool is exhausted.
>>> I will try to run it again and see if it works.
>>
>> The patches to reclaim the anon bdevs faster is small enough to be
>> pushed to older stable kernels, so you should be able to use it
>> eventually.
>>
>> As a workaround, you can still delete the old subvolumes to get the
>> space back but perhaps at a slower rate and wait until the deleted
>> subvolumes are cleaned. That there's no way to get the number of used
>> anon bdevs makes it harder unfortunatelly.


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