From: Hugo Mills <hugo@carfax.org.uk>
To: "krzf83@gmail.com " <krzf83@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: is space really freed after deleting large subvolume?
Date: Fri, 14 Oct 2011 09:45:05 +0100 [thread overview]
Message-ID: <20111014084504.GI21931@carfax.org.uk> (raw)
In-Reply-To: <CAJ1PRSk0BVoYw89C0RYejbRF-4QdrKkA_J94Kf+Y7r-u=w+aHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]
On Fri, Oct 14, 2011 at 07:17:44AM +0200, krzf83@gmail.com wrote:
> Just a idea: I don't know if btrfs works like that or not but idea
> would be that b-tree filesystem should be able to "loose" or "discard"
> branches be removing a node. Cut a tree node and branches will fall
> off - and get overwrited as empty space sometime in future (just like
> during data deletion).
>
> If subvolume is filesystem in filesystem (don't know to what extend
> this is true in btrfs) then sub-filesystem could be re-formated but
> severing it links to its branches.
Subvolumes each have their own FS-tree, so if it were just a matter
of the FS tree, then yes, you'd be right. Sadly, it isn't. Even on
other filesystems, you still have to perform at least one operation
per extent to mark that extent as unused, so that it can be reclaimed.
On btrfs, there's a little more work than that involved (but not
much more). Since btrfs can make CoW copies of files, you can end up
with the same blocks on disk being used by several different parts of
the filesystem. This applies both to data extents and to metadata
blocks. In order to make it possible to know when a block (or set of
blocks) can be reclaimed to be overwritten at some later date, the
blocks are all reference-counted, so each block knows how many things
point to it. Updating and checking the reference count is the thing
that takes time, and can't really be short-circuited.
What btrfs can do is, as you suggest, unlink the FS-tree for the
subvolume immediately so that it's no longer visible. It can then
clean up all the references from that tree in the background -- which
is exactly what it does do.
> Reason for this if of course fast and not io costly deletion of large
> number of files.
It just ain't that simple, I'm afraid. Getting rid of files is a
complicated business.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Nothing right in my left brain. Nothing left in ---
my right brain.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2011-10-14 8:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-13 16:14 is space really freed after deleting large subvolume? krzf83@gmail.com
2011-10-13 16:21 ` Hugo Mills
2011-10-13 16:57 ` krzf83@gmail.com
2011-10-13 18:06 ` krzf83@gmail.com
2011-10-13 19:22 ` krzf83@gmail.com
2011-10-13 20:01 ` David Pottage
2011-10-13 21:03 ` krzf83@gmail.com
2011-10-14 17:26 ` Maciej Marcin Piechotka
2011-10-13 16:29 ` Roman Mamedov
2011-10-14 5:17 ` krzf83@gmail.com
2011-10-14 8:45 ` Hugo Mills [this message]
2011-10-14 17:12 ` Bruce Guenter
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=20111014084504.GI21931@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=krzf83@gmail.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