From: "Yan, Zheng " <yanzheng@21cn.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Disk space accounting and subvolume delete
Date: Wed, 12 May 2010 13:02:07 +0800 [thread overview]
Message-ID: <AANLkTikzNWS11qycrI94k69PFEZJWpAezwuOF6nmw_PF@mail.gmail.com> (raw)
In-Reply-To: <20100511154518.GA11710@untroubled.org>
On Tue, May 11, 2010 at 11:45 PM, Bruce Guenter <bruce@untroubled.org> =
wrote:
> On Tue, May 11, 2010 at 08:10:38AM +0800, Yan, Zheng =A0wrote:
>> This is because the snapshot deleting ioctl only removes the a link.
>
> Right, I understand that. =A0That part is not unexpected, as it works=
just
> like unlink would. =A0However...
>
>> The corresponding tree is dropped in the background by a kernel thre=
ad.
>
> 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. =A0Apparently th=
e
> 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 be=
en
>> 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 f=
or
> sync. =A0Am I misunderstanding something?
>
Dropping a tree can be lengthy. It's not good to let sync wait for hour=
s.
=46or most linux FS, 'sync' just force an transaction/journal commit. I=
don't
think they wait for large operations that can span multiple transaction=
s to
complete.
Yan, Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-05-12 5:02 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
2010-05-12 5:02 ` Yan, Zheng [this message]
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=AANLkTikzNWS11qycrI94k69PFEZJWpAezwuOF6nmw_PF@mail.gmail.com \
--to=yanzheng@21cn.com \
--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).