linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Moshe <moshe@zadarastorage.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs wastes disk space after snapshot deletetion.
Date: Mon, 4 Feb 2013 10:56:52 -0500	[thread overview]
Message-ID: <20130204155652.GB2275@localhost.localdomain> (raw)
In-Reply-To: <997C7B3B2B234B0ABBD6CFA921215298@moshePC>

On Mon, Feb 04, 2013 at 02:08:01AM -0700, Moshe wrote:
> Hello,
> 
> If I write large sequential file on snapshot, then create another snapshot, 
> overwrite file with small amount of data and delete first snapshot, second 
> snapshot has very large data extent and only small part of it is used.
> For example if I use following sequence:
> mkfs.btrfs /dev/sdn
> mount -o noatime,nodatacow,nospace_cache /dev/sdn /mnt/b
> btrfs sub snap /mnt/b /mnt/b/snap1
> dd if=/dev/zero of=/mnt/b/snap1/t count=15000 bs=65535
> sync
> btrfs sub snap /mnt/b/snap1 /mnt/b/snap2
> dd if=/dev/zero of=/mnt/b/snap2/t seek=3 count=1 bs=2048
> sync
> btrfs sub delete /mnt/b/snap1
> btrfs-debug-tree /dev/sdn
> I see following data extents
> item 6 key (257 EXTENT_DATA 0) itemoff 3537 itemsize 53
>     extent data disk byte 1103101952 nr 194641920
>     extent data offset 0 nr 4096 ram 194641920
>     extent compression 0
> item 7 key (257 EXTENT_DATA 4096) itemoff 3484 itemsize 53
>     extent data disk byte 2086129664 nr 4096
>     extent data offset 0 nr 4096 ram 4096
>     extent compression 0
> 
> In item 6: only 4096 from 194641920 are in use. Rest of space is wasted.
> 
> If I defragment like: btrfs filesystem defragment /mnt/b/snap2/t it release 
> wasted space. But I can't use defragment because if I have few snapshots I 
> need to run defragment on each snapshot and it disconnect relation between 
> snapshot and create multiple copies of same data.
> 
> In our test that create and delete snapshots while writing data, we end up 
> with few GBs of disk space wasted.
> 
> Is it possible to limit size of allocated data extents?
> Is it possible to defragment subvolume without breaking snapshots relations?
> Any other idea how to recover wasted space?

This is all by design to try and limit the size of the extent tree.  Instead of
splitting references in the extent tree to account for the split extent we do it
in the file tree.  In your case it results in a lot of wasted space.  This is on
the list of things to fix, we will just split the references in the extent tree
and deal with the larger extent tree, but it's on the back burner while we get
things a bit more stable.  Thanks,

Josef

  reply	other threads:[~2013-02-04 16:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04  9:08 btrfs wastes disk space after snapshot deletetion Moshe
2013-02-04 15:56 ` Josef Bacik [this message]
2013-02-05  9:09   ` Moshe
2013-02-05 14:41     ` Josef Bacik
2013-02-05 15:27       ` Moshe Melnikov
2013-02-06  2:24         ` Liu Bo
2013-02-06  2:34 ` Liu Bo

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=20130204155652.GB2275@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=moshe@zadarastorage.com \
    /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).