Re: What's the difference between `btrfs sub del -c` and `btrfs fi sync`?

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

在 2024/4/27 08:22, intelfx@intelfx.name 写道:
> Hi,
>
> I've been trying to read btrfs-progs code to understand btrfs ioctls
> and one thing evades my understanding.
>
> A `btrfs subvolume delete --commit-{after,each}` operation involves
> issuing two ioctls at the commit time: BTRFS_IOC_START_SYNC immediately
> followed by BTRFS_IOC_WAIT_SYNC. Notably, the relevant comment says
> "<...> issue SYNC ioctl <...>" and the function that encapsulates the
> two ioctls is called `wait_for_commit()`.
>
> On the other hand, a `btrfs filesystem sync` operation involves issuing
> just one ioctl, BTRFS_IOC_SYNC (encapsulated in a function called
> `btrfs_util_sync_fd()`).
>
> I tried to look at the kernel code for the three ioctls but to my
> untrained eye, they look like they are doing different things with
> different side effects.
>
> What is the difference, and why is it needed (i.e. why are there two
> sets of sync-related ioctls)?

IIRC --commit-after/each only commit the current transaction, and it's
just doing the same `btrfs fi sync` after all/each subvolume deletion.

The reason is to ensure the unlinking (not fully deleting) of the target
subvolume fully committed to disk, so a sudden powerloss after the
deletion won't lead to the re-appearing of the target subvolume(s)


However there is a another behavior involved, `btrfs subvolume sync`,
which is to wait for a deleted subvolume to be fully dropped.
In the case of btrfs subvolume deletion, it can be a heavy load, thus
btrfs only unlink the to-be-deleted subvolume, and mark it for
background deletion.
`btrfs subvolume sync` would wait for any such orphan subvolume to be
deleted.

Thanks,
Qu


>
> Cheers,