All of
 help / color / mirror / Atom feed
From: Timofey Titovets <>
To: Henk Slager <>
Cc: linux-btrfs <>
Subject: Re: Space not return
Date: Fri, 18 Dec 2015 16:58:57 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

thanks for the explanation

2015-12-18 15:49 GMT+03:00 Henk Slager <>:
> On Fri, Dec 18, 2015 at 10:37 AM, Timofey Titovets <> wrote:
>> Hi guys, i catch strange problem:
>> btrfs with mysql, mysql rewrite data, but space consumption only increasing
>> i.e:
>> df -h
>> /dev/sdb1       112G   73G   39G  66% /var/lib/mysql
>> du -hs
>> 43G /var/lib/mysql/
> As the fs is new, the file(s) in this directory might initially have
> large extents. Writing a lot to the file(s), with larger pieces at
> file-offsets that belong to those large extents makes btrfs CoW
> allocate new extents but does not free the original space in the large
> extents (no extent splitting in btrfs).
> You could run:
> # filefrag -k -v /var/lib/mysql/*
> to see what the situation is, but migh be too much data.
> In theory, if you would read and writeback the full offset+size of the
> larger extents, the original large extent space is freed. You get more
> fragmentation then, but should not be big problem on SSD (if
> /dev/sdb1  is that)
> File(s) re-creating with nodatacow mount option on might also be your
> choice. And make sure you have no hidden snapshots somewhere, but I
> assume you have checked that.
> Another brute-force work-around would be to run:
> # btrfs fi defrag -r -v -clzo /var/lib/mysql/
> so to force rewriting info smaller extents, but you probably don't
> want compression on those file(s)
>> btrfs fi df /var/lib/mysql
>> Data, single: total=78.00GiB, used=72.39GiB
>> System, single: total=32.00MiB, used=16.00KiB
>> Metadata, single: total=1.00GiB, used=109.61MiB
>> GlobalReserve, single: total=48.00MiB, used=0.00B
>> This is fresh fs (seven hours old)
>> Created by btrfs-progs 4.1.2
>> Linux 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-3~bpo8+2 (2015-12-14)
>> x86_64 GNU/Linux
>> Btrfsck not found any errors on this device
>> P.S. First i think what it because system have opened files
>> descriptors, but after reboot, space not return
>> If i write file by dd and after delete it, space will returned (with
>> direct io and without)
>> --
>> Have a nice day,
>> Timofey.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to
>> More majordomo info at
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to
> More majordomo info at

Have a nice day,

      reply	other threads:[~2015-12-18 13:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18  9:37 Timofey Titovets
2015-12-18 12:49 ` Henk Slager
2015-12-18 13:58   ` Timofey Titovets [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \
    --subject='Re: Space not return' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.