Btrfs devel - Oct 2011 - is space really freed after deleting large subvolume?

I''m wondering is space really freed after deleting large subvolume?
Will space be immediately available to other data like other
subvolumes?
--
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

On Thu, Oct 13, 2011 at 06:14:03PM +0200, krzf83@gmail.com 
wrote:
> I''m wondering is space really freed after deleting large
subvolume?
   Yes, although if you have snapshots, you may not recover very much
space, as [some of] the data on the subvolume may still be in use by
other snapshots.
> Will space be immediately available to other data like other
> subvolumes?
   No, subvolume deletion is done in the background, and the space
recovered will be returned for use relatively slowly. This is because
the FS has to go through the metadata, updating reference counts for
each extent in the subvolume to work out whether the space can be
recovered or not.

   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
    --- Klytus! Are your men on the right pills? Maybe you should ---    
                         execute their trainer!

On Thu, 13 Oct 2011 18:14:03 +0200
"krzf83@gmail.com " <krzf83@gmail.com> wrote:
> I''m wondering is space really freed after deleting large
subvolume?
> Will space be immediately available to other data like other
> subvolumes?
Currently there seems to be no way to ensure it is instantly available, or to be
precise, the only way to get that is to unmount the FS and mount it again. Not
sync, not "btrfs fi sync" ensure that all cleanup is complete before
they return. Only umount does, and it can take a very long time if you have
deleted a large (differing a lot) subvolume just before that.

-- 
With respect,
Roman

~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."

>   No, subvolume deletion is done in the background, and the space
> recovered will be returned for use relatively slowly. This is because
> the FS has to go through the metadata, updating reference counts for
> each extent in the subvolume to work out whether the space can be
> recovered or not.
>
And what affect this rate of space reclaiming? When does it happen?
Also I guess that if it happens it must lower overall io performance
and rise loadavg ...?
--
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

> And what affect this rate of space reclaiming? When does it happen?
> Also I guess that if it happens it must lower overall io performance
> and rise loadavg ...?
>
and finaly is the performance overhead same as deleting same number of
files in system like ext3? When you delete large number of files in
ext3 (or any other system) you are looking at huge io traffic during
deletion. You are saying that in btrfs if you delete subvolume (that
had many files) you don''t get free space instantenously so when and is
prerformance overhead basicly overaly SAME but in time? higher? lower?
--
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

>>Only umount does, and it can take a very long time if you >>have
deleted a large
>>(differing a lot) subvolume just before that.
does it mean that I won''t be able to cleanly reboot machine after
deleting subvolume with milions of files?

And most important question is if deleting btrfs subvolume with 5mln
requiress less io operations than deleting 5mln of files on normal
filesystem (like ext3) (by rm -rf)???
--
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

On 13/10/11 19:06, krzf83@gmail.com wrote:
>> And what affect this rate of space reclaiming? When does it happen?
>> Also I guess that if it happens it must lower overall io performance
>> and rise loadavg ...?
>>
> and finaly is the performance overhead same as deleting same number of
> files in system like ext3? When you delete large number of files in
> ext3 (or any other system) you are looking at huge io traffic during
> deletion. You are saying that in btrfs if you delete subvolume (that
> had many files) you don''t get free space instantenously so when
and is
> prerformance overhead basicly overaly SAME but in time? higher? lower?
ext3 is slow to delete lots of files because the filesystem is block
based, so if you delete a large file (eg an ISO image), then ext3 has to
make a huge number of updates to the free space map to say that those
blocks are now free.

btrfs like ext4 has support for extents, which can be any size, so
typically if you delete a large file, then it occupies only one extent,
so only that one extent needs to be marked as free, so a lot less I/O.

If you delete a large number of files, then there is no avoiding the
fact that a lot of metadata needs to be updated. In this respect btrfs
is unlikely to be significantly faster than any other filing system.

-- 
David Pottage

--
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

>btrfs like ext4 has support for extents, which can be >any size, so
>typically if you delete a large file, then it occupies only >one extent,
>so only that one extent needs to be marked as free, so a >lot less I/O.
I know, I know. Issue is with many (small) files.
> If you delete a large number of files, then there is no avoiding the
> fact that a lot of metadata needs to be updated. In this respect btrfs
> is unlikely to be significantly faster than any other filing system.
Are you sure? That would mean that instant deletion of subvolume in
btrfs is actualy taking ??SAME?? time and io power in BACKGROUND like
deleting by rm -rf in any filesystem.
Common misconception would be that subvolume deletion is much more
efficient and near zero time consuming. I think it is very important
to clear that up.
--
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

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.
Reason for this if of course fast and not io costly deletion of large
number of files.
--
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

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.

On Fri, Oct 14, 2011 at 09:45:05AM +0100, Hugo Mills
wrote:
>  Updating and checking the reference count is the thing
> that takes time, and can''t really be short-circuited.
I''m curious if you know how ZFS does this.  My boss has used a set of
ZFS systems for backup, and indicates that deleting a snapshot is
instant, and free space is updated immediately with no apparent
background I/O.  I know ZFS only has read-only snapshots, but I would
think it would have some of the same reference counting challenges.

I see reading one of the ZFS presentations that it uses a "birth time"
in each block pointer.  This lets it optimizes the deletion by walking
only a partial set of the nodes.  Still, for any non-trivial deletion it
would have to walk enough nodes to keep the delete from being as quick
as is claimed.

-- 
Bruce Guenter <bruce@untroubled.org>                http://untroubled.org/

On Thu, 2011-10-13 at 23:03 +0200, krzf83@gmail.com
wrote:
> 
> > If you delete a large number of files, then there is no avoiding the
> > fact that a lot of metadata needs to be updated. In this respect
> btrfs
> > is unlikely to be significantly faster than any other filing system.
> 
> Are you sure? That would mean that instant deletion of subvolume in
> btrfs is actualy taking ??SAME?? time and io power in BACKGROUND like
> deleting by rm -rf in any filesystem.
> Common misconception would be that subvolume deletion is much more
> efficient and near zero time consuming. I think it is very important
> to clear that up. 
I may be wrong but it may not be necessary true - the fs may optimize
the deletion so for example if 2 files shares the same extend it is
updated once (it may be beneficial as cost of I/O is bigger then cost of
CPU).

Additionally it means that the btrfs does things asynchronously and we
don''t need to wait for all cleanup (I assume that it is as soon as the
deletion is commited to log). Therefore if deletion takes 100 ms of i/o
and 10 ms of cpu on other fs and 100 ms of i/o and 20 ms of cpu on btrfs
the following code takes 210 ms vs. 120 ms on btrfs in very simplified
model.

unlink("/btrfs/file");
busy_wait(100); // Simulates 100 ms computation

Regards

PS. I''m not btrfs developer but I see at least potential advantages of
asynchronous deletion (or split deletion in 2-phases). I don''t know how
much is implemented.