Extra info

Extra info

[Daniele Testa]

Sorry, did not read the guidelines correctly. Here comes more info:

root@s4 /opt/drives/ssd # uname -a
Linux s4.podnix.com 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

root@s4 /opt/drives/ssd # btrfs --version
Btrfs Btrfs v0.19

root@s4 /opt/drives/ssd # btrfs fi show
Label: none  uuid: 752ed11b-defc-4717-b4c9-a9e08ad64ba6
        Total devices 1 FS bytes used 404.74GB
        devid    1 size 410.50GB used 410.50GB path /dev/md3

Regards,
Daniele

Re: Extra info

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Thu, Dec 18, 2014 at 11:02:34PM +0800, Daniele Testa wrote:
> Sorry, did not read the guidelines correctly. Here comes more info:
> 
> root@s4 /opt/drives/ssd # uname -a
> Linux s4.podnix.com 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

   This is your problem. I think the difficulty is that writes into
the middle of an extent didn't split the extent and allow the
overwritten area to be reclaimed, so the whole extent still takes up
space.

   IIRC, josef fixed this about 18 months ago. You should upgrade your
kernel to something that isn't written in cueniform (like 3.18, say),
and defrag the file in question. I think that should fix the problem.

> root@s4 /opt/drives/ssd # btrfs --version
> Btrfs Btrfs v0.19

   This is also an antique, and probably needs an upgrade too
(although it's less critical than the kernel).

   Hugo.

> root@s4 /opt/drives/ssd # btrfs fi show
> Label: none  uuid: 752ed11b-defc-4717-b4c9-a9e08ad64ba6
>         Total devices 1 FS bytes used 404.74GB
>         devid    1 size 410.50GB used 410.50GB path /dev/md3
> 
> Regards,
> Daniele

-- 
Hugo Mills             | Python is executable pseudocode; perl is executable
hugo@... carfax.org.uk | line-noise.
http://carfax.org.uk/  |
PGP: 65E74AC0          |                                            Ben Burton

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Extra info

[Daniele Testa]

I am running latest Debian stable. However, I used backports to update
the kernel to 3.16.

root@s4 /opt/drives/ssd # uname -a
Linux s4.podnix.com 3.16.0-0.bpo.4-amd64 #1 SMP Debian
3.16.7-ckt2-1~bpo70+1 (2014-12-08) x86_64 GNU/Linux

root@s4 /opt/drives/ssd # btrfs --version
Btrfs v3.14.1

It still reports over-use, so I am running a defrag on the file:

root@s4 /opt/drives/ssd # btrfs filesystem defragment
/opt/drives/ssd/disk_208.img

But I see it slowly eats even more disk space durring the defrag. I
had about 7GB before. When it went down close
to 1GB, I cancelled it as I'm afraid it will corrupt the file if it
runs out of space.

Do you know how btrfs behaves if it runs out of space durring a
defrag? Any other ideas how I can solve it?

Regards,
Daniele


2014-12-18 23:35 GMT+08:00 Hugo Mills <hugo@carfax.org.uk>:
> On Thu, Dec 18, 2014 at 11:02:34PM +0800, Daniele Testa wrote:
>> Sorry, did not read the guidelines correctly. Here comes more info:
>>
>> root@s4 /opt/drives/ssd # uname -a
>> Linux s4.podnix.com 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
>
>    This is your problem. I think the difficulty is that writes into
> the middle of an extent didn't split the extent and allow the
> overwritten area to be reclaimed, so the whole extent still takes up
> space.
>
>    IIRC, josef fixed this about 18 months ago. You should upgrade your
> kernel to something that isn't written in cueniform (like 3.18, say),
> and defrag the file in question. I think that should fix the problem.
>
>> root@s4 /opt/drives/ssd # btrfs --version
>> Btrfs Btrfs v0.19
>
>    This is also an antique, and probably needs an upgrade too
> (although it's less critical than the kernel).
>
>    Hugo.
>
>> root@s4 /opt/drives/ssd # btrfs fi show
>> Label: none  uuid: 752ed11b-defc-4717-b4c9-a9e08ad64ba6
>>         Total devices 1 FS bytes used 404.74GB
>>         devid    1 size 410.50GB used 410.50GB path /dev/md3
>>
>> Regards,
>> Daniele
>
> --
> Hugo Mills             | Python is executable pseudocode; perl is executable
> hugo@... carfax.org.uk | line-noise.
> http://carfax.org.uk/  |
> PGP: 65E74AC0          |                                            Ben Burton

RE: Extra info

[Paul Jones]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3059 bytes --]

Another way to defrag the file is to move the file to another disk and then move it back. I've had trouble with virtual machine disks before (Windows server raw) and this has fixed the problem.

FYI 3.17.2 and beyond seems much better now. No crazy slow downs.

Paul.

-----Original Message-----
From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Daniele Testa
Sent: Friday, 19 December 2014 4:33 AM
To: Hugo Mills; Daniele Testa; linux-btrfs@vger.kernel.org
Subject: Re: Extra info

I am running latest Debian stable. However, I used backports to update the kernel to 3.16.

root@s4 /opt/drives/ssd # uname -a
Linux s4.podnix.com 3.16.0-0.bpo.4-amd64 #1 SMP Debian
3.16.7-ckt2-1~bpo70+1 (2014-12-08) x86_64 GNU/Linux

root@s4 /opt/drives/ssd # btrfs --version Btrfs v3.14.1

It still reports over-use, so I am running a defrag on the file:

root@s4 /opt/drives/ssd # btrfs filesystem defragment /opt/drives/ssd/disk_208.img

But I see it slowly eats even more disk space durring the defrag. I had about 7GB before. When it went down close to 1GB, I cancelled it as I'm afraid it will corrupt the file if it runs out of space.

Do you know how btrfs behaves if it runs out of space durring a defrag? Any other ideas how I can solve it?

Regards,
Daniele


2014-12-18 23:35 GMT+08:00 Hugo Mills <hugo@carfax.org.uk>:
> On Thu, Dec 18, 2014 at 11:02:34PM +0800, Daniele Testa wrote:
>> Sorry, did not read the guidelines correctly. Here comes more info:
>>
>> root@s4 /opt/drives/ssd # uname -a
>> Linux s4.podnix.com 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 
>> x86_64 GNU/Linux
>
>    This is your problem. I think the difficulty is that writes into 
> the middle of an extent didn't split the extent and allow the 
> overwritten area to be reclaimed, so the whole extent still takes up 
> space.
>
>    IIRC, josef fixed this about 18 months ago. You should upgrade your 
> kernel to something that isn't written in cueniform (like 3.18, say), 
> and defrag the file in question. I think that should fix the problem.
>
>> root@s4 /opt/drives/ssd # btrfs --version Btrfs Btrfs v0.19
>
>    This is also an antique, and probably needs an upgrade too 
> (although it's less critical than the kernel).
>
>    Hugo.
>
>> root@s4 /opt/drives/ssd # btrfs fi show
>> Label: none  uuid: 752ed11b-defc-4717-b4c9-a9e08ad64ba6
>>         Total devices 1 FS bytes used 404.74GB
>>         devid    1 size 410.50GB used 410.50GB path /dev/md3
>>
>> Regards,
>> Daniele
>
> --
> Hugo Mills             | Python is executable pseudocode; perl is executable
> hugo@... carfax.org.uk | line-noise.
> http://carfax.org.uk/  |
> PGP: 65E74AC0          |                                            Ben Burton
--
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
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Extra info

[Chris Murphy]

The other thing going on here is that every write is going to be COW,
which isn't ideal for VM images. Another thing that I wonder is what
SSD this is and if it's supporting deterministic TRIM, since discard
is enabled. And I'm not sure that md by default is passing down trim
(?). This is on md raid? What level? If it's 56 then there's a
separate enabler for raid56 discard. In general if this isn't an SSD
that supports queued trim commands you're better off without discard
mount option and just running fstrim manually once a week or even once
a day is OK if it's a very busy SSD, just schedule it for a time when
it's typically idle.

Chris Murphy

Re: Extra info

[Chris Murphy]

On Thu, Dec 18, 2014 at 6:57 PM, Chris Murphy <lists@colorremedies.com> wrote:
> The other thing going on here is that every write is going to be COW,
> which isn't ideal for VM images.

Reminder goes here for setting xattr +C on VM images. You can't set it
after the fact though. Only at the time the file is created. A reflink
copy into a folder with +C will fail. And there's not enough space on
the volume to fully copy it.


-- 
Chris Murphy