From: Bruce Guenter <bruce@untroubled.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: Disk space accounting and subvolume delete
Date: Tue, 11 May 2010 09:45:18 -0600 [thread overview]
Message-ID: <20100511154518.GA11710@untroubled.org> (raw)
In-Reply-To: <AANLkTilDHeJ_aRQSKWUTJgIBhlpLHyNRTy4x4ai_MGJI@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Tue, May 11, 2010 at 08:10:38AM +0800, Yan, Zheng wrote:
> This is because the snapshot deleting ioctl only removes the a link.
Right, I understand that. That part is not unexpected, as it works just
like unlink would. However...
> The corresponding tree is dropped in the background by a kernel thread.
The surprise is that 'sync', in any form I was able to try, does not
wait until all or even most of the I/O is completed. Apparently the
standards spec for sync(2) says it is not required to wait for I/O to
complete, but AFAIK all other Linux FS do wait (the man page for sync(2)
implies as much, as does the info page for sync in glibc).
The only way I've found so far to force this behavior is to unmount, and
that's rather intrusive to other users of the FS.
> We could probably add another ioctl that waits until the tree has been
> completely dropped.
Since the expected behavior for sync is to wait until all pending I/O
has been completed, I would argue this should be the default action for
sync. Am I misunderstanding something?
--
Bruce Guenter <bruce@untroubled.org> http://untroubled.org/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-05-11 15:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 18:23 Disk space accounting and subvolume delete Bruce Guenter
2010-05-10 18:50 ` Josef Bacik
2010-05-11 0:10 ` Yan, Zheng
2010-05-11 15:45 ` Bruce Guenter [this message]
2010-05-12 5:02 ` Yan, Zheng
2010-05-12 21:56 ` Mike Fleetwood
2010-05-31 19:01 ` Bruce Guenter
2010-05-31 20:34 ` Mike Fedyk
2010-06-01 2:32 ` Yan, Zheng
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=20100511154518.GA11710@untroubled.org \
--to=bruce@untroubled.org \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).