From: intelfx@intelfx.name
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
Subject: Re: What's the difference between `btrfs sub del -c` and `btrfs fi sync`?
Date: Sat, 27 Apr 2024 01:14:01 +0200 [thread overview]
Message-ID: <c8bac058c40b15a242d4598172d6a89c2f97608b.camel@intelfx.name> (raw)
In-Reply-To: <71f2d380-9b11-4ed5-949c-0edc1ed56c60@gmx.com>
On 2024-04-27 at 08:36 +0930, Qu Wenruo wrote:
>
> 在 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,
Thanks for the fast reply!
Yes, I'm aware about `btrfs sub sync`. I understand that's a totally
different operation.
What I was asking about was specifically the difference between
`btrfs _filesystem_ sync` and the operation that happens at the end of
a `btrfs subvolume delete --commit-after`.
Or, in kernel terms: what exactly is the difference between issuing a
BTRFS_IOC_SYNC and issuing a BTRFS_IOC_START_SYNC immediately followed
by a BTRFS_IOC_WAIT_SYNC?
It is not immediately obvious that the kernel code for the three ioctls
is equivalent (even if it is). For instance, BTRFS_IOC_SYNC begins with
a call to btrfs_start_delalloc_roots() whereas BTRFS_IOC_START_SYNC
begins with a call to btrfs_orphan_cleanup(), and the subsequent
transaction handling code seems subtly different.
--
Ivan Shapovalov / intelfx /
next prev parent reply other threads:[~2024-04-26 23:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 22:52 What's the difference between `btrfs sub del -c` and `btrfs fi sync`? intelfx
2024-04-26 23:06 ` Qu Wenruo
2024-04-26 23:14 ` intelfx [this message]
2024-04-27 0:04 ` Qu Wenruo
2024-04-28 10:20 ` intelfx
2024-05-02 13:16 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8bac058c40b15a242d4598172d6a89c2f97608b.camel@intelfx.name \
--to=intelfx@intelfx.name \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.