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@xxxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
