Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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 --]

  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