* Space not return
@ 2015-12-18 9:37 Timofey Titovets
2015-12-18 12:49 ` Henk Slager
0 siblings, 1 reply; 3+ messages in thread
From: Timofey Titovets @ 2015-12-18 9:37 UTC (permalink / raw)
To: linux-btrfs
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/
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Space not return
2015-12-18 9:37 Space not return Timofey Titovets
@ 2015-12-18 12:49 ` Henk Slager
2015-12-18 13:58 ` Timofey Titovets
0 siblings, 1 reply; 3+ messages in thread
From: Henk Slager @ 2015-12-18 12:49 UTC (permalink / raw)
To: linux-btrfs
On Fri, Dec 18, 2015 at 10:37 AM, Timofey Titovets <nefelim4ag@gmail.com> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Space not return
2015-12-18 12:49 ` Henk Slager
@ 2015-12-18 13:58 ` Timofey Titovets
0 siblings, 0 replies; 3+ messages in thread
From: Timofey Titovets @ 2015-12-18 13:58 UTC (permalink / raw)
To: Henk Slager; +Cc: linux-btrfs
thanks for the explanation
2015-12-18 15:49 GMT+03:00 Henk Slager <eye1tm@gmail.com>:
> On Fri, Dec 18, 2015 at 10:37 AM, Timofey Titovets <nefelim4ag@gmail.com> 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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> 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
--
Have a nice day,
Timofey.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-12-18 13:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-18 9:37 Space not return Timofey Titovets
2015-12-18 12:49 ` Henk Slager
2015-12-18 13:58 ` Timofey Titovets
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.