Hi Chris, Alex, Hugo,
Running now: Linux archb3 4.6.2-1-ARCH #1 PREEMPT Mon Jun 13 02:11:34
MDT 2016 armv5tel GNU/Linux
Seems to be working fine. I started a defrag, and it seems I'm getting
my space back:
$ sudo btrfs fi usage /home
Overall:
Device size: 1.81TiB
Device allocated: 1.73TiB
Device unallocated: 80.89GiB
Device missing: 0.00B
Used: 1.65TiB
Free (estimated): 159.63GiB (min: 119.19GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 240.00KiB)
Data,single: Size:1.72TiB, Used:1.65TiB
/dev/sda4 1.72TiB
Metadata,DUP: Size:3.50GiB, Used:2.16GiB
/dev/sda4 7.00GiB
System,DUP: Size:32.00MiB, Used:224.00KiB
/dev/sda4 64.00MiB
Unallocated:
/dev/sda4 80.89GiB
I deleted some unfinished torrent, ~10 GB in size, but as you can see,
"Free space" has grown by 60 GB (re-checked now and it's 1 GB more now
- so definitely caused by defrag).
What has changed between 4.6.2 and 4.6.3?
Cheers,
Stan
2016-07-07 12:28 GMT+02:00 Stanislaw Kaminski <stasheck.fora@xxxxxxxxx>:
> Too early report, the issue is back. Back to testing....
>
> 2016-07-07 12:18 GMT+02:00 Stanislaw Kaminski <stasheck.fora@xxxxxxxxx>:
>> Hi all,
>> I downgraded to 4.4.1-1 - all fine, 4.5.5.-1 - also fine, then got
>> back to 4.6.3-2 - and it's still fine. Apparently running under
>> different kernel somehow fixed the glitch (as far as I can test...).
>>
>> That leaves me with the other question: before issues, I 1.6 TiB was
>> used, now all the tools report 1.7 TiB issued (except for btrfs fs du
>> /home, this reports 1.6 TiB). How is that possible?
>>
>> Cheers,
>> Stan
>>
>> 2016-07-06 19:42 GMT+02:00 Chris Murphy <lists@xxxxxxxxxxxxxxxxx>:
>>> On Wed, Jul 6, 2016 at 3:55 AM, Stanislaw Kaminski
>>> <stasheck.fora@xxxxxxxxx> wrote:
>>>
>>>> Device unallocated: 97.89GiB
>>>
>>> There should be no problem creating any type of block group from this
>>> much space. It's a bug.
>>>
>>> I would try regression testing. Kernel 4.5.7 has some changes that may
>>> or may not relate to this (they should only relate when there is no
>>> unallocated space left) so you could try 4.5.6 and 4.5.7. And also
>>> 4.4.14.
>>>
>>> But also the kernel messages are important. There is this obscure
>>> enospc with error -28, so either with or without enospc_debug mount
>>> option is useful to try in 4.6.3 (I think it's less useful in older
>>> kernels).
>>>
>>> But do try nospace_cache first. If that works, you could then mount
>>> with clear_cache one time and see if that provides an enduring fix. It
>>> can take some time to rebuild the cache after clear_cache is used.
>>>
>>>
>>>
>>> --
>>> Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
